ServiceNow ticket leakage exposes a broader NHI governance gap

At a glance

What this is: This blog argues that ServiceNow can become a quiet exposure point for secrets and NHI tokens when users paste credentials into tickets, KBs, attachments and records.

Why it matters: It matters because IAM and NHI teams need visibility into collaboration systems where credentials are shared informally, not just in vaults or code.

👉 Read Entro Security's analysis of secrets exposure in ServiceNow tickets

Context

ServiceNow is often treated as an IT workflow system, but it also functions as a high-friction identity boundary where secrets can be pasted into tickets, comments, attachments and configuration records. That creates an NHI governance problem because credentials may be exposed outside the systems where they are originally issued and managed, and traditional access controls do not reliably detect plaintext secrets.

The article’s core claim is that exposure risk in ServiceNow is driven by everyday operational behaviour, not just misconfiguration. For IAM and NHI practitioners, that means the issue is lifecycle control across collaboration data, ticketing workflows and integrations, which is typical in large enterprises rather than an edge case.

Key questions

Q: How should security teams handle secrets exposed in service desk tickets?

A: Treat exposed secrets in service desk tickets as active credential incidents, not documentation issues. Identify the owner, determine whether the secret is still valid, revoke or rotate it immediately, and check for duplicate exposure in other systems. The goal is to contain reuse quickly before a routine support conversation becomes an access path.

Q: Why are collaboration platforms such as ServiceNow risky for NHI governance?

A: Collaboration platforms are risky because they collect the exact material attackers want: tokens, API keys, logs and screenshots that may contain plaintext credentials. They also persist longer than a single incident and often span multiple teams, which increases the chance that one exposed NHI becomes many exposed copies.

Q: What is the difference between secret scanning and secret remediation?

A: Secret scanning finds exposed credentials, but remediation removes the operational risk. A team can detect a token in a ticket and still leave it valid, reused or broadly accessible. Effective remediation includes ownership assignment, revocation, rotation and confirmation that the secret no longer works anywhere it was copied.

Q: When should organisations rotate a secret found in a support ticket?

A: Rotate immediately when the secret is valid, reusable or visible to anyone outside the original need-to-know group. Delaying rotation gives attackers time to replay the credential through integrations or scripts. If the secret has already been copied into other tools, treat the event as a wider NHI exposure, not a single-ticket issue.

Technical breakdown

Why ServiceNow becomes a secrets exposure surface

ServiceNow centralises incidents, changes, knowledge articles and attachments, which makes it a natural place for people to paste logs, screenshots and temporary fixes. The technical problem is that these artefacts can contain plaintext secrets, API keys or NHI tokens, while platform access controls are designed for authorisation, not secret discovery. OCR on attachments matters because image-based screenshots and PDFs often bypass simple text scanning. The result is a hidden credential layer inside operational workflows that can persist longer than the incident itself.

Practical implication: scan ticketing data, attachments and KB content as first-class secret sources, not as low-priority collaboration records.

How contextual secret discovery changes remediation

Detection alone produces a noisy alert stream unless the platform can identify where the secret appeared, what type it is, who exposed it and who can access the artefact. That context turns a generic exposure into an ownership and blast-radius question. In NHI terms, this is the difference between finding a token and understanding whether it is tied to a shared integration, a user-owned script or a reused service account. Cross-platform correlation also matters because the same credential may already exist in GitHub, Slack or other systems.

Practical implication: prioritise tools and workflows that map exposed secrets to owners, access scope and reuse across systems.

Why feedback into ITSM matters for NHI governance

A mature response loop does not stop at scanning. It creates or updates the incident in the same workflow system where the exposure was found, so remediation can be assigned, tracked and escalated without a parallel process. That matters because service accounts, API keys and tokens often fail through delay, not just discovery. For NHI governance, ticketing systems should become enforcement points for response, rotation and validation, especially where support teams are part of the exposure path.

Practical implication: connect secret findings to incident workflows so rotation, revocation and owner notification happen inside normal operations.

Threat narrative

Attacker objective: The attacker aims to recover usable credentials from routine support artefacts and turn them into access to connected systems and integrations.

1. Entry occurs when users paste NHI tokens, API keys or logs into ServiceNow tickets, KB articles or attachments during troubleshooting.
2. Escalation follows when mis-scoped access controls or default-public content let other users or external parties view the exposed artefact.
3. Impact is achieved when the exposed secret remains valid long enough to be reused across integrations, scripts or downstream platforms.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 exposure is an NHI lifecycle problem, not just a ticketing hygiene problem. Secrets pasted into tickets only become manageable when teams treat them as lifecycle objects that can be found, owned, revoked and reviewed. That shifts the problem from helpdesk behaviour to governance over where credentials are allowed to exist. Practitioners should manage ServiceNow as part of the NHI control plane, not as an isolated workflow system.

Context is the difference between alerting and remediation. A secret without source, owner, exposure time and access scope is only a detection event. Once context is attached, the finding becomes actionable for IAM, SecOps and application owners, especially where shared service accounts and reused tokens create wider blast radius. Teams that cannot attach ownership to exposed NHIs will struggle to close incidents quickly.

Ticketing platforms are now part of the secret sprawl problem. The collaboration layer has become a durable storage location for credentials because users copy what is easiest at the moment of troubleshooting. That expands the governance surface beyond code repositories and vaults into helpdesk workflows, KB content and attachments. Security teams should treat collaboration systems as credential-bearing assets.

Continuous rotation becomes mandatory when operational systems expose credentials. If a token can appear in a ticket, the assumption that exposure is rare no longer holds. That makes stale credentials and shared identities harder to justify, especially where the same NHI is reused across multiple applications. Practitioners should tighten rotation, shorten validity and reduce reuse before exposure turns into persistence.

Scoped remediation is the right response to hidden NHI exposure. Not every exposed credential requires the same action, but every exposed credential requires a path to containment. Shared integrations, service accounts and long-lived tokens should be prioritised for revocation or replacement because they convert a single leak into repeated access. Teams should organise response by exposure path, not by alert volume.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• That pattern reinforces why teams should pair discovery with the Guide to the Secret Sprawl Challenge so remediation reaches collaboration systems as well as code.

What this signals

Secret exposure is moving into the operational layer of the enterprise. When tickets, KBs and attachments become credential repositories, the governance problem is no longer limited to source control or vault administration. With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025, the broader signal is that secret sprawl is becoming a normal condition, not an exception.

Ticketing systems now need NHI-specific controls. That means access reviews, attachment scanning, secret classification and automated revocation must extend into ITSM workflows. The practical programme implication is to treat ServiceNow as part of the identity attack surface, not as a passive record system.

Identity blast radius is the right lens for exposed tickets and KBs. Once a token appears in a shared workflow platform, the question becomes how far it can spread before rotation, not whether the original user intended harm. Teams should align response with the 52 NHI Breaches Analysis and reduce reuse wherever one secret can touch many systems.

For practitioners

• Scan collaboration systems for exposed credentials Include ServiceNow tickets, KB articles, CMDB fields, comments and attachments in secret discovery routines. OCR should be enabled for screenshots and PDFs because secrets often hide in non-text artefacts.
• Attach ownership to every exposed NHI Map each exposed token or key back to an application owner, integration owner or service owner so remediation can be assigned without manual detective work. Shared credentials should be flagged as higher risk.
• Automate rotation after confirmed exposure Trigger revocation or replacement workflows when a valid secret is found in a ticketing system. Use short-lived replacements where possible and verify downstream dependencies before closing the incident.
• Restrict public knowledge content and templates Review KB visibility, ticket templates and troubleshooting forms so they do not encourage credential pasting or expose outdated runbooks. Default access should be narrow, with explicit approval for broader viewing.
• Correlate exposures across systems Check whether the same secret also appears in code repositories, chat systems or other collaboration tools. Duplicate exposure is a strong indicator that the credential has already spread beyond the original incident.

Key takeaways

• ServiceNow can become a credential-bearing system when users paste secrets into tickets, KBs and attachments.
• Exposure response must include owner mapping, duplicate search and fast rotation, not just alerting.
• Practitioners should fold ITSM platforms into NHI governance because collaboration data now sits on the attack surface.

Key terms

• Non-Human Identity: A non-human identity is any credentialed entity used by software rather than a person. It includes service accounts, API keys, tokens, certificates and autonomous agents. These identities often outnumber human users and need lifecycle controls because they can be reused, exposed and abused at machine speed.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across tools, logs, tickets, code and collaboration platforms. It creates hidden attack paths because secrets are copied faster than they are revoked. The problem is operational as much as technical, so discovery without cleanup leaves residual risk.
• Identity Blast Radius: Identity blast radius is the scope of damage that follows from the exposure or misuse of one identity or secret. It depends on how widely the credential is reused, what systems it can reach and how long it remains valid. Narrowing blast radius is a core NHI governance objective.

What's in the full article

Entro Security's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step integration behaviour for scanning incidents, problems, change requests and knowledge base content.
• Feature-level context fields showing exposure source, owner attribution, access scope and where the same secret appears elsewhere.
• How the platform feeds detected exposures back into ServiceNow as new incident tickets through webhook or API workflows.
• Examples of attachment scanning, including OCR for screenshots and PDFs, that are not expanded on in this analysis.

👉 Entro Security's full blog covers ServiceNow scanning, context fields and remediation workflow details

Deepen your knowledge

ServiceNow secrets exposure and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring ticketing systems into scope without slowing operations, it is worth exploring.