Topic starter
03/06/2026 7:24 pm
TL;DR: ServiceNow instances can become long-lived repositories for passwords, tokens, API keys and internal records when knowledge bases, tickets and automation tables are mis-scoped, according to Entro Security’s analysis of recent incidents. The governance gap is not visibility alone: IAM teams are assuming that sensitive data stays where workflows originally placed it, but ITSM platforms routinely break that premise.
Editorial analysis by NHI Mgmt Group, based on content published by Entro Security: “Leaking Tickets: Secrets Exposure in ServiceNow (Part 1)”.
Key questions
Q: Why do ServiceNow tickets and knowledge bases leak secrets so easily?
A: Because support workflows encourage people to paste whatever unblocks the request, including tokens, config snippets and attachments with sensitive data.
Q: Why do misconfigured ServiceNow knowledge bases create identity risk?
A: Because the platform can expose records even when the login boundary is protected.
Q: How do security teams keep NHI credentials out of ITSM workflows?
A: They need a rule that support records may reference secrets, but never store them.
Practitioner guidance
- Inventory secrets inside ITSM records Scan tickets, knowledge base articles, attachments, scripts and credential tables for passwords, API keys, tokens and certificates, then classify where each value is stored and who can see it.
- Tighten record-level access boundaries Review knowledge base ACLs, public widgets and user-criteria settings so internal articles cannot be reached through cloned or default-read configurations.
- Separate workflow convenience from secret storage Replace pasted credentials in incidents and tasks with short-lived references, vault-backed retrieval or approved handoff processes that do not persist in the record.
Bottom line: ServiceNow can become a long-lived secrets repository when support records, knowledge articles and automation assets are allowed to carry credentials.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
03/06/2026 7:28 pm
ServiceNow is not just a workflow tool, it is an identity container. When tickets, KB articles and automation records hold secrets, the platform becomes part of the NHI lifecycle whether teams model it that way or not. The important shift is to stop treating support content as inert business data and start treating it as governed identity-adjacent material. Practitioners need to view ITSM as a control boundary, not only an operations layer.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What should teams do when ServiceNow is used to integrate cloud and CI/CD systems?
A: Treat the instance as a governed identity surface and review every integration for stored credentials, broad read access and orphaned automation accounts. The question is not whether ServiceNow is operationally useful, but whether its integrations have the same revocation, scoping and offboarding discipline as the systems they connect.
👉 Read our full editorial: ServiceNow secrets exposure shows how ITSM becomes an identity risk