A cohort of support agents experienced simultaneous password expiration across their Zendesk instance, raising questions about how expiration policies are actually configured and enforced. The incident suggests that password lifecycle management may not operate on individual creation or update dates as administrators typically assume, but rather on a fixed organisational cadence—potentially a blanket 90-day reset applied across all users regardless of when credentials were last changed. This discrepancy between expected behaviour and actual system operation points to a critical gap in how CX teams understand their identity and access controls, particularly as support platforms increasingly handle sensitive customer data and integrate with downstream systems.
The timing of this discovery matters considerably. Whilst the Zendesk issue itself appears to be a configuration or documentation problem rather than a security vulnerability, it occurs against a backdrop of escalating authentication-related threats across the CX technology stack. ServiceNow's recent disclosure of maximum-severity flaws enabling unauthenticated code execution and privilege escalation demonstrates that once attackers bypass initial access controls, credential-based defences collapse—only 37% of post-authentication actions are blocked in typical environments. For teams already managing complex integrations between Zendesk, ServiceNow, and other platforms, the question becomes whether simultaneous password expiration events are actually a feature designed to force periodic resets, or a symptom of misconfigured policies that could leave agents locked out during critical support windows.
The operational risk here extends beyond a single platform. If password expiration policies are opaque or behave unexpectedly, teams cannot reliably forecast access disruptions, plan rotation schedules, or audit compliance with their own security baselines. CX leaders should treat this as a signal to audit password policies across their entire stack—not just Zendesk—and establish clear documentation of when and why credentials reset. The alternative is discovering mid-shift that your entire support team has been locked out, or worse, that attackers have exploited the confusion around credential management to maintain persistent access.
I don't recall seeing this before - but about 10 agents all had their passwords expire on the same day. I thought this was based on the last time they set their password or from the account creation date - not just every 90 days? Is it based on a Zendesk date or last pwd update/creation date?
ServiceNow released security patches for three new maximum-severity AI Platform vulnerabilities that can be exploited in code injection, SQL injection, and privilege escalation attacks. [...]