TL;DR: ServiceNow tickets, knowledge bases, attachments and CMDB records can all become exposure points for secrets and NHI tokens, with Entro Security describing scanning, contextualisation and remediation workflows across those surfaces. The real issue is not detection alone but governance over where credentials appear, who can access them, and how quickly they are revoked.
At a glance
What this is: This is a vendor analysis of how ServiceNow becomes a hidden exposure surface for secrets and NHI tokens across tickets, knowledge bases, attachments and CMDB records.
Why it matters: IAM, IGA and PAM teams need to treat ITSM content as part of the credential estate because exposure, ownership and revocation all become governance issues once secrets are pasted into shared workflow systems.
Context
ServiceNow is often treated as a workflow system, but in practice it can become part of the credential surface when users paste API keys, tokens, screenshots, logs and scripts into tickets or related records. The governance gap is not only whether a secret can be found, but whether the organisation knows where that secret propagates and who can see it.
For NHI governance, the problem is broader than ticket hygiene. If support workflows, KB articles, CMDB entries and attachments can all carry reusable credentials, then the lifecycle of the secret extends beyond the system that created it. That turns ServiceNow into an identity risk accumulator unless scanning, ownership and offboarding are tied to the same operational process.
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. Once that information lands in a ticketing or knowledge base system, it can persist far beyond the original incident unless teams apply NHI lifecycle management and content controls.
Q: Why do ServiceNow exposures create more risk than a one-off leaked credential?
A: Because ServiceNow content can be replicated across tickets, comments, attachments, scripts and knowledge articles. The result is broader read access, slower discovery and a larger revocation problem. A single pasted secret can become many exposure points, especially when access controls are inherited or mis-scoped.
Q: How do security teams know whether exposed ServiceNow secrets are actually contained?
A: They need to confirm that the secret has been found, owned, revoked or rotated, and removed from every accessible copy. If any linked record, attachment or downstream script still exposes the same credential, containment has not happened. Context and asset linkage are what make that determination possible.
Q: Should organisations move secrets handling out of ServiceNow entirely?
A: Not necessarily, but they should stop relying on ServiceNow as an informal repository for credentials. If the platform is part of support and integration workflows, then secret handling must be governed with scanning, access restrictions and lifecycle controls. The question is not whether ServiceNow is used, but whether it is governed as a secret-bearing system.
Technical breakdown
Why ticket systems become secret repositories
ServiceNow tickets are designed to move issues through support workflows, not to enforce secret handling discipline. That makes them a natural place for credentials to appear in plain text when users paste logs, error messages, config files or tokens while troubleshooting. Once a secret lands in a ticket, it can be copied into comments, attachments, linked knowledge articles or downstream scripts. The technical problem is not only storage. It is distribution through a system whose default business purpose creates multiple reading and replication paths. In NHI terms, the ticket becomes an unplanned secret distribution point.
Practical implication: treat ITSM records as part of secret discovery and revocation scope, not just as helpdesk artifacts.
How access scoping turns exposure into lateral risk
A secret in ServiceNow is only exploitable at scale if access scope is broader than the original reporter expected. Knowledge Base articles, attachments and CMDB records often inherit permissions from default settings, cloned templates or mis-scoped ACLs, which can make sensitive content visible to more users than intended. The key issue is that visibility is decoupled from ownership. A credential may be created by one team, pasted by another and accessed by many more. That is why contextual inventory matters: you need to know who exposed it, who could read it and where else it appears before you can judge actual blast radius.
Practical implication: validate ACLs, public KB exposure and attachment permissions as part of NHI access review, not as separate helpdesk administration.
What detection plus workflow integration changes
Detection alone is incomplete if the alert sits outside the operational process that can revoke or remediate the exposed secret. Entro Security describes a pattern where exposed secrets are scanned, contextualised and then fed back into ServiceNow through an incident workflow. Mechanically, that closes the loop between discovery and action by attaching ownership, location and exposure context to the finding. In governance terms, this matters because exposed NHIs are not just a security event. They are a lifecycle event. The organisation needs a reliable path from finding a secret to revoking, rotating or offboarding the underlying credential before reuse or reuse-by-proxy occurs.
Practical implication: wire secret findings into the same incident and remediation path you use for other NHI lifecycle actions.
Threat narrative
Attacker objective: The attacker objective is to discover reusable credentials in a business workflow system and use them to access connected services or data.
- Entry occurs when users paste API keys, tokens or other secrets into ServiceNow tickets, knowledge bases or attachments during troubleshooting.
- Exposure expands when mis-scoped access controls, default public settings or inherited permissions make those records readable by more people than intended.
- Impact follows when the exposed credential can be reused across integrations, scripts or services before the secret is rotated or revoked.
Breaches seen in the wild
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
ServiceNow is not just a system of record, it is a secret propagation layer. When users paste tokens, keys or credentials into tickets and KB articles, the platform becomes part of the credential estate whether security teams intended that or not. The governance mistake is to treat workflow content as non-sensitive by default. Practitioners need to recognise ServiceNow as an exposure surface that can extend secret lifetime across multiple business processes.
Hidden secret exposure is a lifecycle failure, not a scanning failure. Detection matters, but it does not solve the problem if exposed NHIs remain valid after discovery. The deeper issue is that ownership, access scope and revocation are split across teams and tools. That creates a gap between finding a secret and making it unusable, which is where risk persists.
Context is the control plane for exposed credentials. A raw secret finding is weak without the source record, access list, exposure time and linked service. Security teams need this context to decide whether the issue is a local ticket cleanup or a wider NHI incident. The practical conclusion is that exposure analytics must attach identity, access and lifecycle metadata to every finding.
Uncontrolled ServiceNow content creates trust debt in NHI programmes. The organisation inherits obligations from every copied log, screenshot and script fragment that lands in a ticket. Over time, those artifacts accumulate into a governance debt that outlives the original incident. The implication is that NHI controls must extend into collaboration and ITSM systems, not stop at dedicated secret stores.
ServiceNow secret exposure is an access-governance problem disguised as support hygiene. Teams that frame it only as user behaviour miss the structural issue: the system permits credentials to be stored, replicated and rediscovered across ordinary support workflows. The right conclusion is not that helpdesk users are careless, but that access policy and lifecycle controls were never designed to contain this kind of secret spread.
From our research library:
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
- 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.
- Read next: Ultimate Guide to NHIs
What this signals
Secret-bearing workflows are now an identity governance issue. When support systems can hold tokens, API keys and screenshots with embedded credentials, the control objective shifts from discovery alone to lifecycle containment. Organisations should extend NHI inventory, access review and revocation discipline into ITSM platforms and knowledge repositories, because that is where secrets often live long enough to be reused.
Exposure context matters more than raw detection. A secret finding without the record, owner and access scope only tells you that a problem exists. The practical value comes from linking the secret to the service it unlocks, the people who can read it and the systems where it reappears. That is the line between cleanup and containment.
ServiceNow secret leakage creates governance debt that compounds over time. Every copied token, pasted log or embedded credential increases the likelihood that support tooling becomes an unintended distribution channel. The programme implication is simple: teams that do not govern these records will keep rediscovering the same exposure in different places.
For practitioners
- Map ServiceNow content to the credential estate Treat tickets, KB articles, CMDB records and attachments as discoverable secret locations and include them in your NHI inventory and review scope.
- Tighten public and inherited access paths Review ACLs, cloned KB permissions and attachment visibility to make sure exposed credentials are not readable outside the teams that need them.
- Build secret findings into incident workflow Route exposed secrets into the same triage, ownership and escalation process used for other NHI incidents so revocation starts from the finding itself.
- Replace hardcoded integration secrets Move ServiceNow automations and third-party links away from embedded credentials and toward scoped secrets with explicit ownership and rotation.
Key takeaways
- ServiceNow support content can function as an unintended secret repository when users paste credentials into tickets, KB articles and attachments.
- The real risk is not just discovery but spread, because access scope and downstream copies can keep an exposed credential usable longer than expected.
- Security teams should tie ticket scanning, ownership attribution and revocation into the same NHI governance workflow.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and 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-02 — Secret Leakage | The article centres on secrets and tokens exposed in ServiceNow workflows. |
| NHI-03 — Vulnerable Third-Party NHI | The post highlights third-party integrations and exposed API keys used in SNOW workflows. | |
| NHI-05 — Overprivileged NHI | Mis-scoped access controls and broad visibility drive the exposure impact described here. | |
| Recommendation — Scan ServiceNow records for leaked secrets and remove exposed credentials from tickets, KBs and attachments. Review third-party integrations for credential exposure and revoke unsafe NHI trust paths. Reduce read access to secret-bearing records and enforce least privilege on ITSM content. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central when exposed tokens must be rotated or revoked. |
| Recommendation — Apply IA-5 to rotate or revoke exposed authenticators once they appear in ServiceNow content. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on who can read exposed records and how scope widens risk. |
| Recommendation — Use PR.AA-05 to verify and tighten permissions on tickets, attachments and knowledge articles. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed secrets in workflow systems enable credential access and downstream movement. |
| Recommendation — Map exposed ServiceNow secrets to TA0006 and TA0008 to prioritise containment of reusable credentials. | ||
Key terms
- Secret-Bearing Workflow: A business workflow system that can store, move or expose credentials as part of normal operations. In this context, ServiceNow tickets, KBs, attachments and CMDB records become part of the secret surface because users paste tokens or keys into them during support activity.
- Exposure Context: Exposure context is the combination of data sensitivity, location, accessibility, and business impact that determines how risky a dataset is. In practice, it lets security teams move beyond raw access counts and judge whether an allowed permission creates acceptable or excessive risk.
- NHI Lifecycle Containment: The practice of making an exposed non-human identity unusable across every place it appears. It covers ownership, rotation, revocation and offboarding for machine credentials that have escaped into collaboration or ITSM systems. The aim is to stop a secret from remaining valid after discovery.
- Credential scope drift: Credential scope drift occurs when the access a key effectively receives at runtime is broader than the permissions intended at creation. It often shows up through weak endpoint checks, overly permissive roles, or poor revocation handling, and it turns a narrow credential into an uncontrolled access path.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 28, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org