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.
When ServiceNow Becomes a Secret-Bearing System
ServiceNow is not the problem by itself. The risk appears when teams use it as a place to store credentials, tokens, keys, or passwords outside a dedicated secrets control. At that point, the platform is part of the secret lifecycle and must be treated as sensitive identity material, not just as a workflow tool. Secrets Management Guide is useful background for the governance patterns that matter here.
If ServiceNow participates in support, change, or integration workflows, the question becomes whether secrets are discoverable, restricted, rotated, and retired with the same discipline as anywhere else. That includes scoping access tightly, avoiding long-lived exposure in tickets or attachments, and ensuring the platform does not become an informal repository that outlives the original operational need.
What Changes Operationally If Secrets Stay Inside It
Keeping secrets in ServiceNow can be acceptable only when the handling model is deliberate. The practical difference is between using the platform to orchestrate a secret-related process and using it as the storage location for the secret itself. Orchestration is a workflow issue; storage is a secrets-management issue, and the controls required are much stricter.
That distinction matters because support tooling often has broad readership, long retention, and many downstream integrations. If a password or API token is embedded in a ticket, note, field, or attachment, it may be copied, indexed, exported, or retained far beyond the original workflow. A governed design should minimise where the secret appears, who can render it, and how quickly it is removed or replaced.
For a broader control view, the OWASP Non-Human Identity Top 10 aligns well with the access and lifecycle issues raised by secret-bearing systems, especially where service credentials are tied to automated workflows. The related OWASP Cheat Sheet Series also reinforces the need for strong handling patterns across authentication and secret storage.
When to Keep It, When to Move It, and What to Govern Either Way
The right decision is usually not an absolute move-out decision. If ServiceNow is only passing references to an external vault or orchestration layer, it can remain part of the process. If it is storing active credentials, then the governance bar should be much higher, and a dedicated secrets system is usually the cleaner control boundary.
That means three things should be true: secrets should be easy to find and inventory, access should be narrower than general ticket visibility, and rotation or revocation should be possible without waiting for manual cleanup. The strongest pattern is to make ServiceNow a controlled participant in the workflow, not the authoritative home for the secret.
Where secrets handling is currently informal, the first correction is usually visibility. Organisations should identify where credentials are appearing, whether they are still needed, and whether the platform has a documented owner for scanning, approval, and removal. The harder the integration sprawl, the more important that ownership becomes.
Risk and Threat Considerations
Secrets stored in ServiceNow can create accidental broad exposure because tickets, comments, attachments, and exported records are often more widely accessible than a true secrets store. The risk is not just leakage, it is also long retention, weak review discipline, and secondary copying into downstream systems that are harder to clean up.
Failure mechanism: A credential is embedded in a support record or attachment, then accessed by a wider audience, retained after the operational need ends, or reused after rotation should have occurred.
Impact: An exposed secret can enable unauthorised access, lateral movement, or persistent compromise, especially if the secret grants production or integration privileges.
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 addresses the attack surface, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | ServiceNow ticket data can expose stored credentials and tokens. |
| NHI-07 — Long-Lived Secrets | Stored credentials in ServiceNow can persist past their intended use. | |
| NHI-05 — Overprivileged NHI | Support workflows often expose secrets to broader access than needed. | |
| Recommendation — Scan records for leaked secrets and move active credentials out of ticket content. Enforce short-lived credentials and rotate anything that remains visible in support workflows. Restrict access paths so only the minimum required roles can view secret-bearing records. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credentials in ServiceNow need lifecycle controls for issuance, storage, rotation, and revocation. |
| AC-6 — Least Privilege | Secret-bearing records should not be visible to broad ticket audiences. | |
| Recommendation — Apply lifecycle controls to issue, rotate, and revoke any credentials handled in ServiceNow. Limit visibility of secret-bearing records to the smallest practical set of roles. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | ServiceNow secrets handling depends on restricted access to sensitive records. |
| A.8.24 — Use of cryptography | Secrets in workflows should be protected with stronger handling than plain text storage. | |
| Recommendation — Define and enforce access rules for any secret-bearing ServiceNow content. Protect secret material with appropriate cryptographic and handling safeguards. | ||
| OWASP ASVS | V14 — Data Protection | Secret-bearing records require protection against disclosure and unsafe storage. |
| V16 — Security Logging and Error Handling | Detection and auditability matter when secrets may appear in workflow content. | |
| Recommendation — Treat stored credentials as protected data and avoid persisting them in plain text. Log and review access to secret-bearing workflow data. | ||
| CIS Controls v8 | CIS-5 — Account Management | Credential governance depends on knowing where active access exists and who owns it. |
| Recommendation — Inventory and govern accounts or credentials referenced through ServiceNow workflows. | ||
Practitioner Guidance
What to prioritise: Classify every secret-related ServiceNow use case as either workflow orchestration or secret storage. If the platform is holding the secret itself, treat that as a control exception that needs explicit approval, ownership, and compensating controls.
What to verify: Confirm that access to secret-bearing records is narrower than general case visibility, that scanning exists for secrets in text fields and attachments, and that rotation or revocation can be executed quickly when exposure is found. A ticketing platform should never be the only place a live secret exists.
Practitioner takeaway: ServiceNow can be part of a governed secret workflow, but it should not be the informal system of record for credentials; if the secret lives there, the handling model must be as strict as any other sensitive secret repository.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org