ServiceNow secrets exposure shows how ITSM becomes an identity risk

At a glance

What this is: Entro Security’s analysis shows ServiceNow can turn everyday ITSM workflows into a durable secrets and NHI exposure surface when access controls, attachments and automation data are not tightly governed.

Why it matters: IAM, NHI and PAM teams need to treat ITSM content as governed identity-adjacent data, because a single mis-scoped ticket or knowledge base can expose credentials, internal records and downstream system access.

By the numbers:

• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read Entro Security's analysis of ServiceNow secrets exposure and NHI risk

Context

ServiceNow is an ITSM platform, but in practice it also becomes a holding area for credentials, tokens, attachments, internal chat transcripts and system details. The issue is not that the platform was built for secrets management, but that workflows, tickets and knowledge bases often accumulate sensitive material faster than teams can classify or review it.

That creates an identity governance problem as much as a data handling problem. When service tickets, knowledge articles and automation tables store non-human identity material, IAM, PAM and NHI teams inherit exposure that spans users, service accounts and connected systems, often without a single control boundary.

The incidents in this analysis are not unusual edge cases. They reflect what happens when a central workflow system is treated as operationally convenient but not as a security-sensitive repository with its own access, retention and detection rules.

Key questions

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

A: Treat them as exposed identity material, not harmless workflow data. Search historical tickets, attachments and knowledge articles for passwords, tokens, certificates and internal system details, then remove or quarantine records that contain them. Tie each exposed secret to an owner, revoke anything no longer needed, and apply stricter retention and access controls to future records.

Q: Why do service desks and ITSM platforms create NHI exposure risk?

A: Because they often store operational credentials needed by integrations, automation and support workflows. When tokens, API keys or service account details live in tickets or scripts, a compromise of the workflow platform can reveal reusable access material for downstream systems. That turns a support repository into a privilege-concentrating identity surface.

Q: What breaks when knowledge base access is mis-scoped in ServiceNow?

A: The assumption that internal content stays internal. Public or overbroad knowledge base settings can expose tickets, credentials, PII and configuration data to people who were never meant to see them. Once those records are searchable or downloadable, the exposure tends to spread beyond the original misconfiguration.

Q: Who is accountable when ServiceNow leaks credentials or internal data?

A: The platform owner, the data owner and the identity governance team all share responsibility, because the exposure sits at the intersection of content access, secrets handling and integration risk. Accountability should include who approved the access model, who owns the leaked secret and who can revoke any downstream credentials.

Technical breakdown

Why ServiceNow becomes a secret-sprawl repository

ServiceNow is designed to centralise work, so it naturally centralises the data that supports work. That includes incident notes, configuration snippets, credentials pasted during troubleshooting, and attachments containing logs or exports. The technical problem is that these objects often inherit workflow permissions rather than explicit secret-handling policy, so a record that was safe to create is not necessarily safe to retain, search, or replicate across modules. Once sensitive content lands in a ticket or knowledge article, it can persist far longer than the operational need that created it.

Practical implication: Treat ticketing and knowledge content as sensitive data stores, not just collaboration records.

How access-control misconfiguration exposes internal data

ServiceNow exposure often starts with ACL drift, public knowledge base settings, or fallback authentication paths that were never intended for broad access. The technical weakness is not one bug alone, but the combination of module-specific controls, cloned configurations, and inconsistent enforcement across portals, widgets and APIs. When one layer is mis-scoped, attackers or researchers can enumerate records, retrieve attachments, or bypass the intended user boundary. In identity terms, the platform behaves like a mixed-trust repository unless every access path is explicitly constrained.

Practical implication: Review every public-facing or self-service path separately, not just the main login experience.

Why automation tables and credentials create NHI exposure

ServiceNow often stores non-human identity material because it integrates with CI/CD, cloud and monitoring systems that need API keys, service account tokens or certificates. Those secrets may be embedded in scripts, credential tables or configuration records, which turns the platform into an indirect secret store. The technical issue is that these records are usually created for operational convenience, not for lifecycle control, rotation or granular retrieval auditing. If the platform is compromised or overscoped, the attacker gets a bridge to downstream systems rather than just a support record.

Practical implication: Inventory all ServiceNow-held secrets and map each one to an owner, purpose and rotation path.

Threat narrative

Attacker objective: The objective is to turn a workflow platform into a source of reusable credentials, internal data and downstream access paths.

1. Entry begins when a public knowledge base, exposed attachment, stolen credential or vulnerable platform path allows access to ServiceNow content that was assumed to be internal.
2. Escalation follows when the exposed record set reveals passwords, API tokens, admin credentials or configuration details that let the attacker or researcher move from one record to broader instance access.
3. Impact occurs when those credentials or records are used to read tickets, retrieve attachments, enumerate sensitive data, or pivot into connected systems through stored non-human identity material.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 governance problem disguised as content sprawl. The platform is not just leaking documents, it is leaking the credentials, tokens and system details that operational teams paste into those documents. That makes the issue broader than data loss prevention because the exposed material often represents active identity material, not static information. Practitioners should treat ServiceNow content as part of the NHI governance surface.

Identity does not stay confined to purpose-built vaults, and that assumption is broken here. ServiceNow was designed for case management and workflow, not as a durable repository for secrets, yet operational reality pushes secrets into tickets, KB articles and scripts. Once that happens, the old assumption that sensitive identity material lives only in approved security tools no longer holds. The implication is that identity governance must follow the data path, not just the designated control stack.

Public knowledge base access and fallback login are examples of control-path fragmentation. The same platform can be SSO-protected, self-service exposed and API-accessible at once, which means the effective trust boundary is determined by the weakest path. That fragments accountability because one configuration can look safe while another path remains open. Practitioners should assume multi-path exposure until every access route is verified separately.

Standing access to stored secrets creates identity blast radius across connected systems. When ServiceNow contains service account tokens, API keys or admin credentials, compromise of the workflow platform can become compromise of the downstream estate. That means the platform is not simply a source of sensitive data, it is a privilege concentrator. The governance implication is to stop measuring exposure only inside ServiceNow and start measuring the reachable systems behind it.

Privileged access review is too slow for the lifecycle of secrets hidden in workflow records. Secrets pasted into tickets or KBs can persist for months, while conventional review cycles assume a stable entitlement boundary and a visible owner. In practice, the record may outlive the credential, the owner may change, and the exposure may already have been replicated elsewhere. Practitioners should treat secrets embedded in ITSM as a lifecycle failure, not just a clean-up task.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of organisations are currently using a dedicated secrets management system, according to The 2024 State of Secrets Management Survey.
• The 52 NHI Breaches Analysis shows repeated cases where exposed credentials and overbroad access turned routine systems into breach accelerators, according to 52 NHI Breaches Analysis.

What this signals

Identity blast radius inside ITSM is the concept teams should start measuring. ServiceNow is not just a workflow tool when it holds live secrets, attachments and integration credentials. Once that happens, a ticketing platform can become an identity-adjacent repository with reach far beyond the help desk, and the operational question becomes how quickly exposed material can be found, owned and revoked.

The current pattern suggests that many organisations still treat secrets in support tooling as a hygiene issue rather than a control boundary. That is why a platform-level search for exposed credentials must sit alongside PAM, NHI inventory and workflow governance. The teams that can map where credentials are pasted, copied and retained will be better positioned to reduce downstream access risk.

For broader control design, this topic aligns with the direction of zero trust and NHI governance rather than with isolated application hardening. A workflow system with multiple trust paths, stored credentials and broad user populations should be assessed as a privileged identity surface, not only as a records system. The practical signal is simple: if sensitive records can be created faster than they can be reviewed, the programme is behind.

For practitioners

• Classify ServiceNow content by sensitivity tier Tag tickets, knowledge articles, attachments and configuration exports that may contain passwords, tokens, certificates or internal system paths. Apply stricter retention, search and sharing rules to those records than to ordinary service content.
• Audit every access path separately Test public knowledge bases, self-service portals, fallback login pages, APIs and direct record access as distinct trust boundaries. A platform that is protected in one path can still leak data through another.
• Inventory and own all NHI material stored in ITSM Identify service account tokens, API keys and credentials stored in scripts, credential tables or attachments. Assign an owner, define rotation expectations and remove anything that has no explicit business justification.
• Scan for secrets in historical tickets and articles Run discovery across archived incidents, requests, comments and knowledge articles to find exposed secrets and internal identifiers. Remediate both the record and any downstream credentials that may have been copied or reused.
• Separate workflow convenience from privileged access Limit who can view attachments, scripts and credential-bearing records, even if they can create or update tickets. The control objective is to stop ordinary workflow users from becoming indirect custodians of reusable access material.

Key takeaways

• ServiceNow can become an identity risk surface when tickets, knowledge articles and automation records contain live secrets or downstream access details.
• Mis-scoped access, fallback login paths and stored integration credentials turn a workflow platform into a privilege-concentrating system.
• Identity teams should inventory exposed secrets in ITSM, tighten access by record type and treat support tooling as part of NHI governance.

Key terms

• Identity Blast Radius: The scope of systems, data and credentials that become exposed when one identity surface is compromised. In workflow platforms, blast radius often expands because tickets, knowledge articles and integrations can all carry reusable access material that reaches beyond the original record.
• Control-Path Fragmentation: A condition where different access routes to the same platform are protected inconsistently. One path may be locked down while another remains open through fallback login, public content or an API, which makes the real trust boundary weaker than the documented one.
• Workflow-Derived Secret Exposure: The accidental storage of credentials, tokens or certificates inside operational records created for support or collaboration. These secrets are often embedded during troubleshooting and then persist in tickets, attachments or scripts long after the original purpose has passed.

What's in the full article

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

• Walkthroughs of each cited ServiceNow exposure pattern, including how the access failure occurred.
• The specific incident details behind the knowledge base leak, credential exposure and RCE chain.
• Why certain ServiceNow modules and configurations were more exposed than others in the examples discussed.
• The vendor's transition into mitigation guidance in Part 2, which is outside this analysis.

👉 Entro Security's full post covers the incident examples, exposed data types and the move to mitigation guidance in Part 2.

Deepen your knowledge

ServiceNow secrets exposure and workflow-driven NHI risk are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme needs to govern secrets where people actually work, this is a practical place to start.