ServiceNow secrets exposure shows how ITSM becomes an identity risk

At a glance

What this is: This analysis shows how ServiceNow can turn into a persistent secrets exposure surface when tickets, knowledge bases and automation records are misconfigured or over-trusted.

Why it matters: IAM and NHI teams need to treat ITSM platforms as governed identity and secrets surfaces, not just support systems, because exposed credentials and tokens can outlive the workflow that created them.

Context

ServiceNow is widely used as the operational hub for IT, HR, security and DevOps workflows, which is exactly why it becomes a sensitive-data concentration point. Once tickets, knowledge bases and automation tables start carrying secrets, the platform stops being a neutral record system and becomes part of the identity risk surface.

The governance problem is not simply whether users can log in. The real issue is whether access scope, content scope and automation scope are all aligned tightly enough to prevent credentials, tokens and internal records from becoming durable assets in the wrong place.

For IAM and NHI programmes, ServiceNow is a reminder that workflow platforms can quietly store non-human identities and the secrets that authenticate them. That makes mis-scoped support tooling a lifecycle problem, not just a permissions problem.

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 misconfigured ServiceNow knowledge bases create identity risk?

A: Because the platform can expose records even when the login boundary is protected. If articles, widgets or attachments are readable by the wrong audience, internal data and non-human identity secrets become accessible outside the intended trust boundary. The risk comes from record scoping, not just authentication strength.

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. Use vault-backed retrieval, short-lived references and explicit ownership for any service account token or API key that touches ServiceNow. That keeps the credential lifecycle separate from the ticket lifecycle.

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.

Technical breakdown

Why ServiceNow becomes a secrets repository

ServiceNow is built to centralise operational work, so users naturally paste incident details, attachments, tokens and configuration material into the same records that drive support and automation. That convenience is also the exposure mechanism: once secrets enter tickets, KB articles or credential tables, they inherit the retention and access model of the platform instead of the lifecycle of the secret itself. In practice, this creates a long-lived repository for data that should have stayed ephemeral. The technical issue is not only storage, but reuse of workflow records as an informal secret transport layer.

Practical implication: Treat tickets and knowledge articles as potential secret-bearing records and define explicit handling rules for credentials, tokens and keys.

How mis-scoped access controls expose internal records

ServiceNow instances often mix public-facing portals, authenticated users and privileged administrators across the same content model. When knowledge base ACLs, user criteria or widget permissions are cloned or left too broad, internal content can become readable outside the intended audience even if the main instance is protected by SSO. The article’s incidents show that the failure is often at the content layer, not the authentication layer. That means a secure login boundary does not prevent exposure if the records themselves are reachable through misconfigured modules or direct object paths.

Practical implication: Review access controls at the record and widget level, not just the login layer, and remove any public or broad-read exposure paths.

How automation tables turn NHI credentials into latent risk

ITSM platforms that integrate with cloud services, CI/CD tools and monitoring systems often need to store API keys, service account tokens or other non-human identity credentials. Once those values are embedded in credential tables, scripts or support workflows, they can be exposed to administrators, abused through script access or recovered during platform compromise. This matters because the secret is now bound to a business workflow rather than a bounded workload. The result is an identity object that is both operationally useful and difficult to govern with ordinary ticketing controls.

Practical implication: Map every ServiceNow-integrated secret to an owner, a purpose and a revocation path, then remove credentials that only exist for workflow convenience.

Threat narrative

Attacker objective: The attacker’s objective is to extract usable credentials and internal data from the ITSM platform and then leverage that access for broader compromise.

1. Entry occurred through public knowledge base access, leaked credentials or exploitation of platform vulnerabilities that allowed attackers to reach internal ServiceNow data.
2. Credential access followed when exposed passwords, API keys or tokens were harvested from KB articles, tickets, JavaScript or database records.
3. Escalation and lateral movement became possible when the compromised records led to admin-level visibility, broader instance access or downstream system reach.
4. Impact came from bulk exposure of support transcripts, employee records, configuration data and live production secrets.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• Indian government breach 2021: Sakura Samurai found exposed .git and .env files across Indian government sites, leaking 35 credential pairs, private keys and personal data.

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 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.

Access control at the workflow layer is where exposure most often starts. The article’s examples show that SSO can be in place while public KB articles, broad ACLs or cloned permissions still expose sensitive records. That means the control failure is often scoping, not authentication. Teams that only assess login policy miss the real path by which internal records become externally visible.

Secret sprawl in ServiceNow is a lifecycle failure, not a storage accident. Secrets entered during troubleshooting often remain long after the incident that justified them. Once they are copied into attachments, tickets or scripts, the platform preserves them beyond their intended trust window. The practitioner conclusion is that secret governance has to follow the record lifecycle, not just the originating workload.

Mis-scoped ITSM permissions create a wider identity blast radius than many teams expect. One exposed ticket can surface user data, configuration details and NHI credentials at the same time, which collapses separation between human, machine and workflow identities. That is why governance of ServiceNow belongs in the same conversation as NHI inventory, offboarding and access review. Teams should assume cross-domain leakage unless they explicitly design against it.

Public-facing support surfaces deserve the same scrutiny as internet-facing applications. The platform’s operational value encourages broad sharing, but that does not reduce the confidentiality obligations attached to its contents. The named concept here is workflow-borne secret exposure: sensitive credentials become durable because a business workflow makes them easy to place and hard to retire. Practitioners should treat that pattern as a standing governance risk.

From our research library:

• 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.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

ServiceNow-style workflow systems are becoming high-value identity containers because they concentrate tickets, attachments, automation records and the secrets that support them. That changes the governance question from "is the platform authenticated" to "what sensitive material is now durable inside a record that was never meant to be a secret store".

Workflow-borne secret exposure: The operational risk is not only that a credential leaks, but that a business process makes the leak persistent and difficult to notice. When NHIs outnumber human identities by 25x to 50x in modern enterprises, the amount of machine and workflow material flowing through ITSM systems makes this problem a governance issue rather than an edge case, according to the Ultimate Guide to NHIs.

For practitioners

• 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.
• Map NHI ownership and offboarding Assign owners to every ServiceNow-stored service account token or API key, then define revocation and replacement steps when the workflow, integration or vendor relationship changes.

Key takeaways

• ServiceNow can become a long-lived secrets repository when support records, knowledge articles and automation assets are allowed to carry credentials.
• The most important failure mode is mis-scoped access to content, because record-level exposure can exist even when the main login path is controlled.
• ITSM platforms need lifecycle governance for secrets and non-human identities, not just authentication controls for users.

Key terms

• Workflow-borne Secret Exposure: A pattern where credentials, tokens or keys become embedded in business workflows instead of staying in dedicated secret stores. In ServiceNow-like systems, the issue is persistence and reach, because records are designed to be shared, retained and searched long after the secret should have been retired.
• Record-Level Access Control: Record-Level Access Control limits who can view, edit, or delete a specific data record. It applies permissions at the individual record or row level, using identity, role, attributes, ownership, or policy rules to decide access. This control is common in systems handling sensitive customer, patient, financial, or case data.
• Non-Human Identity Lifecycle: The Non-Human Identity Lifecycle is the full sequence of creation, use, control, review, and retirement for identities that are not tied to a person. It covers service accounts, API keys, certificates, tokens, bots, and AI agents, including issuance, rotation, monitoring, revocation, and secure decommissioning across systems and environments.

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.