They showed that broad internal use creates a hidden exposure layer because not every user can spot a secret in a ticket or attachment. Entro Security’s analysis addresses how to handle this at scale in its full article.
Why This Matters for Security Teams
The ServiceNow incidents mattered because they exposed a support-operations blind spot: tickets, attachments, and chat workflows are often treated as low-risk collaboration surfaces, even though they can carry live secrets. That creates a hidden exposure layer for passwords, API keys, session tokens, and certificates. Once a secret lands in a ticket, the operational question is no longer whether it was meant to be shared, but how quickly it can be found, revoked, and replaced.
This is a familiar pattern in NHI security. NHIs are often embedded in workflows that feel routine to support staff, which makes the exposure easy to miss until a leak is discovered by audit, incident response, or an attacker. NHI Management Group research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, reinforcing that support tooling is part of the identity attack surface. For broader context, see The 52 NHI breaches Report and the Ultimate Guide to NHIs — Why NHI Security Matters Now. In practice, many security teams encounter ticket-based secret exposure only after a support case has already been searchable for days or weeks.
That is why support operations cannot be treated as a simple workflow issue. It is an identity governance problem that happens to live inside ITSM.
How It Works in Practice
The incidents showed that broad internal access does not equal safe internal access. In a support environment, the normal path is for users, admins, or automation to paste diagnostics into tickets so an issue can be resolved quickly. If those diagnostics include secrets, the ticketing system becomes a persistence layer for credentials. This is especially risky because support teams are optimized for speed and traceability, not for secret hygiene.
Operationally, the right response is to reduce the chance that secrets are stored in tickets in the first place, then assume that some will still get through. That means combining controls across intake, detection, and response:
- scan tickets, attachments, and comments for secrets at creation time and on ingestion;
- quarantine or redact sensitive data before broader visibility is granted;
- route suspected secrets into a revocation workflow with owners, timestamps, and escalation paths;
- tie every exposed secret to the NHI it authenticates so rotation can happen fast.
That last point matters because secrets are not just data, they are active identity material. The NHI Management Group’s JetBrains GitHub plugin token exposure illustrates how a single exposed token can become an operational incident, while the 52 NHI Breaches Analysis shows why exposed credentials should be treated as a live security event, not a documentation problem. External guidance from the Anthropic — first AI-orchestrated cyber espionage campaign report also reinforces that automated systems can rapidly exploit leaked credentials once they are available.
These controls tend to break down when support teams rely on ad hoc paste-ins from privileged admins, contractors, or automation pipelines because the workflow itself preserves the secret long enough to be reused elsewhere.
Common Variations and Edge Cases
Tighter ticket screening often increases handling time, requiring organisations to balance response speed against exposure reduction. That tradeoff is real, especially when support operations are measured on resolution time and customer satisfaction. The guidance is evolving, but current practice suggests that exception paths should be narrowly scoped and heavily monitored rather than broadly exempted.
There are a few edge cases worth calling out. First, not every sensitive item in a ticket is a secret; logs, error codes, and config references can be safe if they are stripped of credentials. Second, some environments need support teams to see short-lived diagnostics for break-fix work, but those should use JIT access and ephemeral secrets rather than long-lived credentials. Third, shared inboxes and third-party support portals can extend exposure well beyond the original helpdesk platform, so downstream copies matter as much as the source record.
This is also where human process and machine enforcement must work together. RBAC alone does not solve the problem if a user is already entitled to open the case but not entitled to see the embedded secret. Best practice is to pair secret detection with automated revocation, ticket redaction, and owner notification. For a wider perspective on why credential sprawl becomes a breach multiplier, see the Anthropic report and the NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now. The practical lesson is simple: support operations become dangerous when visibility is wider than revocation discipline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Ticketed secrets need fast rotation and revocation after exposure. |
| NIST CSF 2.0 | PR.AC-4 | Support visibility must follow least-privilege and need-to-know access. |
| CSA MAESTRO | Support operations around secrets affect agentic and automated workflows too. |
Treat support systems as governed workflow surfaces with monitoring and escalation.
