Security teams should keep ServiceNow as the workflow and approval front end while ensuring secrets remain stored and governed in a dedicated secrets management control. That separation lets teams centralize requests, approvals, rotation, and revocation without exposing credentials in the ITSM layer. The practical goal is to reduce manual handling, preserve auditability, and keep access decisions tied to policy rather than convenience.
Why ServiceNow Should Orchestrate Requests, Not Hold Secrets
ServiceNow works well as the request and approval system of record because it gives security teams a durable workflow trail, ownership, and separation of duties. The critical boundary is that approval evidence is not the same as secret custody. If the platform that routes requests also becomes the place where credentials are exposed, teams create an avoidable blast radius and make audits harder, not easier. OWASP’s Non-Human Identity Top 10 is useful here because it highlights how machine access becomes risky when governance and secret handling are collapsed into one layer.
Practitioners often get this wrong by treating the ITSM record as evidence that the access itself is controlled, when the real control depends on where the secret lives, who can retrieve it, and how quickly it can be revoked. In practice, many security teams discover that their approval process is sound only after a request path has already been used to expose credentials in the workflow layer.
How the Request-to-Secrets Split Should Work
The clean operating model is simple: ServiceNow owns the intake, ticketing, approver routing, and audit trail, while the secrets platform owns storage, issuance, rotation, retrieval policy, and revocation. That split preserves the business value of ServiceNow without turning it into a credential vault. The request should describe what access is needed, for how long, and under what approval policy. The approval should then trigger an action in the secrets system, not a manual copy-paste of the secret into a ticket, comment, attachment, or email thread.
This distinction matters because secrets are not just sensitive data; they are active authority. Once a token, API key, certificate, or password is visible in the ITSM layer, the access model inherits every weaker permission boundary around that system. A safe design therefore uses ServiceNow as the control plane for workflow and the dedicated secrets store as the enforcement point for actual access. Where integrations are available, the ticket can pass an approval state or short-lived request token to the secrets platform, which then provisions or reveals the secret according to policy.
- Keep the secret out of the ticket payload, notes, and attachments.
- Make the approval event machine-readable so the secrets system can enforce policy automatically.
- Use rotation and revocation as normal closure steps, not as exceptional cleanup.
- Record who approved access, but do not store the credential where the approval was recorded.
That model also improves accountability because the audit trail shows request, decision, issuance, and revocation as separate events. For teams aligning the workflow to broader control expectations, the NIST Cybersecurity Framework 2.0 helps frame the governance and recovery expectations around identity-enabled access, even though it does not replace the need for a dedicated secrets control.
The guidance breaks down when teams use ServiceNow as a convenience layer for manual credential delivery instead of a policy trigger for controlled secret access.
Where the Model Breaks Down and What Teams Miss
Tighter workflow control often increases integration effort, so organisations must balance cleaner governance against the operational cost of connecting ServiceNow to a separate secrets platform. The tradeoff is usually worth it, but only if the approvals remain meaningful and the downstream enforcement is automatic. If the secrets team still has to interpret free-text tickets or chase approvals by hand, the model becomes slow without becoming safer.
There is also a real edge case around emergency access. Break-glass processes may need expedited approval paths, but they still should not require exposing long-lived secrets inside ServiceNow. Another common variation is temporary access for onboarding, testing, or vendor support. Those cases may justify different duration limits or narrower scopes, but they do not justify storing credentials in the workflow tool. The consensus is strong on one point: workflow records can prove that access was authorised, but they should not become a substitute for a secrets control boundary.
For teams building the control stack, the practical question is whether the approval system can be swapped out without changing where secrets live. If the answer is yes, the architecture is usually healthier; if the answer is no, the organisation has probably fused governance and custody too tightly.
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 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Secrets and Credential Exposure | ServiceNow-requested secret access can expose machine credentials if custody is blurred. |
| Recommendation — Keep secrets out of ITSM records and enforce retrieval only through the secrets platform. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Credential Management | Approval-driven secret access depends on governed identity and access processes. |
| Recommendation — Tie access approval to controlled credential issuance and revocation. | ||
| CIS Controls v8 | 6 — Access Control Management | The workflow must enforce least privilege and timely removal of access paths. |
| Recommendation — Use access control workflows to approve, limit, and revoke secret access. | ||
Practitioner Guidance
What to prioritise: Separate approval authority from credential custody. ServiceNow should decide whether access is allowed, while the secrets platform decides how the secret is issued, revealed, rotated, and revoked.
What to verify: Confirm that no token, password, certificate, or API key can be exposed in tickets, comments, attachments, email notifications, or approval logs. Also verify that closure of the request triggers revocation or rotation when the access is time-bound.
Common mistake: Treating a well-documented ITSM workflow as if it were a secrets management control. A clean audit trail is useful, but it does not compensate for weak custody, excessive retrieval rights, or manual secret handling.
What good looks like: The requester sees the request status in ServiceNow, the approver sees the policy context, and the secrets system performs the actual privileged action without disclosing the credential to the workflow layer.
Practitioner takeaway: If ServiceNow can explain and authorise access without ever becoming the place where the secret exists, the organisation has preserved both auditability and real control.
Related resources from NHI Mgmt Group
- How should security teams manage secrets so they can contain a compromise quickly across development and SaaS services?
- How should security teams govern access requests in ServiceNow without weakening IAM controls?
- How should security teams manage access requests without creating ticketing bottlenecks?
- How should security teams handle access approvals when requests arrive faster than humans can review them?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
