How should security teams handle secrets stored in ServiceNow tickets and knowledge bases?

Why This Matters for Security Teams

ServiceNow tickets and knowledge bases are often treated as operational memory, but they can become long-lived containers for passwords, API keys, certificates, session tokens and internal hostnames. That makes them identity systems by accident. Once a secret is copied into a ticket or article, it tends to be replicated, forwarded, exported, indexed and retained far beyond its intended lifespan.

This is not a niche hygiene issue. NHIMG research shows that 28% of secrets incidents now originate outside code repositories, in tools like Jira and Confluence, and are 13% more likely to be critical than code-based leaks in the The State of Secrets Sprawl 2026 research. For teams managing service desk records, the practical lesson is simple: ticketing content can expose real production access even when code scanners report a clean bill of health. The OWASP OWASP Non-Human Identity Top 10 also reinforces that non-human credentials need lifecycle controls, not just discovery.

In practice, many security teams encounter exposed ticket secrets only after an unrelated investigation, rather than through intentional review of workflow content.

How It Works in Practice

The right response is to treat ServiceNow as an exposure surface and then apply the same discipline used for source code, chat, and CI/CD artifacts. Start with targeted searches across incidents, requests, change records, attachments and knowledge articles for secret patterns, authentication headers, private keys, connection strings and environment details. Then classify the finding by type, owner, blast radius and current validity. The operational goal is not just removal. It is to determine whether the secret can be revoked, replaced or safely ignored because it is already dead.

NHIMG guidance on the Guide to the Secret Sprawl Challenge and the Shai Hulud npm malware campaign shows how quickly exposed secrets are operationalised once attackers find them. That is why current guidance suggests pairing cleanup with revocation, rotation and access reduction. If a ticket stored a live credential, the owning system should be updated first, then the record quarantined or redacted, then retention rules tightened so the same failure does not reappear.

• Search historical records, not just open tickets.
• Quarantine attachments before permanent deletion if legal hold or audit requirements exist.
• Map each secret to an owner and confirm whether it is still in use.
• Rotate or revoke anything valid, then verify dependent services still function.
• Restrict who can create, view and export ticket attachments containing sensitive data.

For implementation discipline, align the workflow with the OWASP Non-Human Identity Top 10 and review the Reviewdog GitHub Action supply chain attack as a reminder that exposed credentials are often reused elsewhere. These controls tend to break down when ServiceNow content is exported into reports or synced into downstream systems because the secret then escapes the original deletion path.

Common Variations and Edge Cases

Tighter ticket and knowledge-base controls often increase support overhead, requiring organisations to balance cleaner records against slower collaboration and more false positives. That tradeoff is real, especially in environments where teams paste temporary access details into incidents during live response or vendor support.

Best practice is evolving on how aggressive redaction should be for historical content, because some organisations need evidence retention for compliance while others can safely purge more quickly. When legal hold applies, move the record into a quarantined state and redact only the secret material, rather than deleting the entire ticket. When secrets appear in knowledge articles, treat the article as published guidance with security impact, not just documentation, and rebuild it with safe placeholders and ownership notes.

Edge cases matter. Shared admin inboxes, MSP-managed queues and integration-generated tickets can all hide the real owner, so the cleanup process needs a clear assignment rule before revocation starts. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because static secrets left in records are especially hard to defend once they have been copied into multiple workflows. The operational standard should be simple: if the record can expose access, it should be treated as a secret-bearing asset until proven otherwise.

Related resources from NHI Mgmt Group

• Why do ServiceNow tickets and knowledge bases leak secrets so easily?
• What should security teams do about secrets hidden in SharePoint?
• How should security teams handle risks from AI browser extensions?
• Why do ServiceNow tickets leak secrets so often?