Subscribe to the Non-Human & AI Identity Journal

Why do ServiceNow tickets leak secrets so often?

ServiceNow combines broad user participation, troubleshooting noise, and multiple content types, so credentials can enter tickets, attachments, and knowledge articles without anyone treating them as long-lived secrets. Once exposed, they require lifecycle management across the NHI estate, not just ticket cleanup.

Why ServiceNow tickets become a secret spill point

ServiceNow is not usually the root cause. It is where messy operational work becomes visible: users paste logs, screenshots, config snippets, vendor output, and temporary access details into one record, then assume the ticket lifecycle will naturally contain the exposure. It will not. Once a token, password, or certificate lands in a ticket, it can spread into comments, attachments, exports, and linked knowledge content, turning routine support into NHI debt.

This is why secret leakage in ITSM platforms is an NHI problem, not just a help desk hygiene issue. The Guide to the Secret Sprawl Challenge shows how quickly secrets escape the systems that generated them, while the OWASP Non-Human Identity Top 10 treats secret handling as a lifecycle control problem, not a one-time redaction task. The real risk is that ticket content often outlives the incident, the analyst, and the original access need. In practice, many security teams discover ticket-based exposure only after the secret has already been reused elsewhere, rather than through intentional detection.

How ticket content turns into exploitable secret sprawl

ServiceNow tickets leak secrets because they sit at the intersection of urgency, broad access, and mixed content types. A user under pressure shares a password reset link, a support engineer pastes an API key to prove a failure, or an automation workflow stores a token in a field that was never designed for credential data. After that, the ticket is replicated into notifications, search indexes, exports, integrations, and sometimes knowledge articles. The exposure is no longer confined to one record.

That is why remediation has to be lifecycle-based. A secret found in a ticket should be treated like any other compromised NHI credential: identify where it was used, revoke or rotate it, check for reuse across systems, and confirm that downstream copies are removed. The operational burden is real; Akeyless reports that the average time to mitigate a leaked secret is 36 hours, which reflects the manual cleanup many teams still rely on. NHIMG’s 52 NHI Breaches Analysis and Guide to the Secret Sprawl Challenge both show the same pattern: once secrets move into collaboration and ITSM tools, containment becomes harder than initial detection.

  • Classify ticket fields, attachments, and comments as potential secret-bearing content.
  • Apply automated detection at ingestion and before outbound notifications or exports.
  • Make revocation and rotation the default response, not manual cleanup.
  • Restrict who can view raw attachments and linked operational artifacts.

The Anthropic – first AI-orchestrated cyber espionage campaign report is a useful reminder that tool-enabled workflows can be chained quickly once credentials are exposed. These controls tend to break down when tickets are exported into downstream BI, audit, or knowledge systems because the secret copies are no longer governed by the original incident record.

Where the standard controls break down

Tighter redaction and attachment scanning often increases operational friction, requiring organisations to balance support speed against exposure reduction. That tradeoff is real, especially in high-volume service desks where users expect fast resolution and analysts rely on copy-paste diagnostics.

Best practice is evolving, and there is no universal standard for this yet, but current guidance suggests treating ticketing platforms as semi-trusted collaboration surfaces rather than secure secret stores. The most common failure modes are exceptions and edge cases: emergency break-glass access, vendor escalation threads, attachments created by mobile users, and knowledge articles copied from resolved incidents. If those paths are not covered, secrets leak through the gaps even when the primary workflow is controlled.

The most practical mitigation is to combine policy with workflow design. Use JIT access where possible, keep secrets short-lived, and avoid embedding long-lived credentials in support artifacts. For platform-level governance, align ServiceNow handling with the CI/CD pipeline exploitation case study and the The 52 NHI breaches Report, because both show how quickly exposed credentials become movement opportunities once they are discoverable. In practice, this guidance breaks down in heavily customised ServiceNow environments with multiple integrations because secret copies proliferate across workflows faster than they can be detected.

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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-05 Addresses secret lifecycle and exposure handling in NHI systems.
NIST CSF 2.0 PR.DS-1 Protects data in transit and at rest, including secrets stored in ticket content.
NIST AI RMF GOVERN Supports governance for workflows where tool use and automation expand exposure risk.

Treat ticket fields, attachments, and exports as protected data requiring redaction and access limits.

Related resources from NHI Mgmt Group