Notifications
Clear all
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.
NHIMG editorial — based on content published by Entro Security: Leaking Tickets, Secrets Exposure in ServiceNow (Part 1)
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
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.
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.
Q: What breaks when knowledge base access is mis-scoped in ServiceNow?
A: The assumption that internal content stays internal.
Practitioner guidance
- Classify ServiceNow content by sensitivity tier Tag tickets, knowledge articles, attachments and configuration exports that may contain passwords, tokens, certificates or internal system paths.
- Audit every access path separately Test public knowledge bases, self-service portals, fallback login pages, APIs and direct record access as distinct trust boundaries.
- Inventory and own all NHI material stored in ITSM Identify service account tokens, API keys and credentials stored in scripts, credential tables or attachments.
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.
👉 Read Entro Security's analysis of ServiceNow secrets exposure and NHI risk →
ServiceNow secrets exposure: what IAM teams need to fix?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
03/06/2026 7:28 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ServiceNow secrets exposure shows how ITSM becomes an identity risk
