ServiceNow access automation raises new identity governance questions

At a glance

What this is: This is an analysis of a ServiceNow and Veza access-request integration that automates approvals and provisioning while preserving auditability.

Why it matters: It matters because IAM teams must decide where automation improves access velocity and where it can quietly widen governance gaps across human, NHI, and delegated workflows.

By the numbers:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% only partial visibility.
• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Veza's ServiceNow integration guide for automated access requests

Context

Access-request automation is an identity governance problem before it is a workflow problem. The primary question is how to preserve approval integrity, entitlement accuracy, and audit evidence when a request moves from a service catalog into downstream provisioning across multiple systems.

For NHI and human IAM programmes, the hard part is not the click-to-approve experience. It is maintaining a trustworthy source of entitlement truth, reliable identity matching, and clear approval boundaries when workflow orchestration spans ServiceNow, an identity authorization platform, and target systems.

This is especially relevant where identity data is fragmented across directories, SaaS applications, and privileged platforms. The operational goal is faster fulfilment without creating duplicate approvals, broken mappings, or ungoverned access paths, a pattern that often mirrors the control debt described in the Ultimate Guide to NHIs.

Key questions

Q: How should security teams govern access requests in ServiceNow without weakening IAM controls?

A: Keep the request experience separate from the control decision. Users can request access through ServiceNow, but entitlement matching, SoD checks, approval routing, and audit logging should remain policy-governed in the identity layer. That separation prevents a friendly interface from becoming a weak approval path and keeps compliance evidence tied to the actual access outcome.

Q: What breaks when access data is fragmented across many systems?

A: When access data is fragmented, organisations lose the ability to reconstruct who has what and why. That creates weak reviews, slow remediation, and poor segregation of duties decisions. The failure is usually not a missing approval step. It is an incomplete identity picture that makes every downstream governance action less reliable.

Q: How do teams know whether automated provisioning is actually working?

A: Look for two signals. First, new users and role changes should receive the right access without manual rework. Second, revocation should happen cleanly when the identity leaves or changes scope. If either side relies on tickets, exceptions, or cleanup after the fact, the automation is not fully governed.

Q: Who is accountable when a request automation flow grants the wrong access?

A: Accountability sits with the team that owns the workflow logic and the entitlement source of truth, not just the operator who clicked approve. That includes IAM, IGA, and platform owners when identity mapping, approval creation, or catalog synchronisation fails.

Technical breakdown

How catalog-driven access requests work across identity systems

The integration uses a service catalog as the user entry point, then maps each selected access profile to a separate requested item. That design matters because every access profile follows its own approval and provisioning path, rather than treating a multi-item request as one undifferentiated transaction. The identity platform acts as the source of truth for access profiles and downstream membership changes, while ServiceNow holds the workflow state, approver records, and audit trail. This pattern reduces manual handoffs, but it also makes data synchronisation and request-state integrity central to security.

Practical implication: treat the catalog as a governed entitlement interface, not a convenience layer.

Identity matching and provisioning APIs in the request flow

The workflow depends on API-driven identity lookup and entitlement assignment. A script layer resolves the person or account in the identity platform, then calls a provisioning endpoint to add that identity to the selected access profile. That sounds straightforward, but the security boundary is in the identity resolution logic, API authentication, and error handling. If the wrong user mapping is returned, the request can still complete successfully from a workflow perspective while granting access to the wrong identity. In governance terms, the quality of the join between systems is as important as the approval itself.

Practical implication: validate identity resolution logic with production data before relying on automated fulfilment.

Why approval workflow design becomes the control point

The article’s strongest technical lesson is that approval creation must be deterministic. The integration relies on business rules to create manager approval, optional IT review, and admin approval in a fixed sequence, with duplicate approval logic disabled. That design avoids the common failure mode where multiple workflow rules create conflicting approvals or orphan requests. The control is not the one-click experience. The control is the ability to guarantee that a request can only progress when the intended approval chain exists, closes, and records state changes consistently.

Practical implication: review approval-creating rules as a control system, not a workflow convenience.

Threat narrative

Attacker objective: The objective is to obtain access to systems or profiles that were not properly governed by the intended approval chain.

1. Entry occurs through the access request process itself, when a user selects one or more access profiles in the catalog and submits business justification for approval.
2. Escalation happens if identity matching, approval logic, or workflow state handling is wrong, because the request can progress into provisioning with unintended entitlement scope.
3. Impact is the automated granting of access across downstream systems, which can create unauthorised access, audit gaps, or duplicate approvals if the workflow is misconfigured.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Access-request automation is only as trustworthy as its entitlement source of truth. When access profiles are distributed across systems, automation can accelerate both compliant fulfilment and governance drift. The discipline shift is from manual ticket handling to entitlement integrity, because the workflow now becomes a policy enforcement surface rather than a service desk convenience.

Approval chains fail when the workflow engine, not the policy model, becomes the authority. The article shows that duplicate approval creation and optional review steps can be controlled in code, but that also means the governance model is embedded in workflow logic. If that logic is inconsistent, the organisation no longer has a policy problem. It has a control implementation problem that will surface as inconsistent access outcomes.

Identity resolution is the hidden control plane in automated provisioning. Matching a requester in ServiceNow to the correct identity in the access platform is not an integration detail, it is a governance dependency. Mis-matched identifiers, stale email values, or partial user records create access decisions that look valid in the ticketing system but are wrong in the identity system.

Operational automation does not remove identity risk, it changes where the risk concentrates. Instead of manual fulfilment errors, teams inherit workflow integrity risk, entitlement synchronisation risk, and audit completeness risk. That means IAM, IGA, and PAM teams should evaluate request automation as a governance architecture, not a productivity feature.

Entitlement orchestration debt: this is the accumulation of workflow rules, approval branches, and identity mappings that make automated access look simple while hiding the real decision logic. Once that debt builds, changes to access policy become harder to verify, harder to audit, and easier to break. Practitioners should treat every automation layer as a governed control boundary.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, according to Ultimate Guide to NHIs.
• For the lifecycle angle, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows why offboarding and rotation controls must stay tied to access governance.

What this signals

With only 5.7% of organisations reporting full visibility into service accounts, access automation programmes need stronger entitlement governance than most workflow projects provide. The real programme risk is not request volume, it is the possibility that high-speed fulfilment obscures poor identity hygiene and stale entitlements.

Entitlement orchestration debt: when approval logic, catalog sync, and identity resolution live in different layers, small workflow changes can create large governance failures. Teams should watch for increasing dependence on scripts and business rules to preserve controls that used to be explicit in policy.

The next maturity step is to connect request automation with lifecycle governance, especially offboarding and recertification, using frameworks such as the NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs. That shift keeps workflow speed from outrunning accountability.

For practitioners

• Map approval logic to a single policy owner Document which business rule, workflow, or policy engine is authoritative for manager approval, IT review, and admin escalation. Remove duplicate approval creators and test that each requested item follows one deterministic path from request to closure.
• Test identity matching with production-like records Validate lookup logic against real email formats, alternate usernames, and incomplete directory data before enabling automatic provisioning. Reconcile how ServiceNow identifiers map to the identity platform so the wrong user cannot inherit a valid approval chain.
• Audit entitlement synchronisation as a control, not a task Review how often catalog items sync from the access platform, what happens to decommissioned profiles, and whether stale profiles remain requestable. Use the Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs as a reference for lifecycle discipline and the NIST Cybersecurity Framework 2.0 for governance alignment.
• Require closed-loop evidence for every fulfilled request Retain who requested, who approved, what was granted, when provisioning occurred, and whether downstream systems actually reflected the change. Link the request record to the resulting entitlement state so audit checks can verify the end state, not just the ticket status.

Key takeaways

• Automated access request flows can improve speed, but they also concentrate governance risk in approval logic, identity matching, and entitlement synchronisation.
• The most valuable control is not the catalog interface itself, but the ability to prove that every granted entitlement matched the approved request and reached the right identity.
• IAM teams should evaluate request automation as a lifecycle governance design, because stale profiles, duplicate approvals, and mis-mapped identities can all produce valid-looking but incorrect access.

Key terms

• Access Orchestration Layer: The access orchestration layer is the part of the workflow where requests, approvals, routing rules, and entitlement decisions combine into a real access outcome. It matters because the service desk can become a control plane when it determines who receives access, under what policy, and with what evidence.
• Entitlement Source Of Truth: The authoritative record of what access exists, who owns it, and how it should be granted or removed. It prevents ticketing tools from inventing ad hoc permissions by forcing each request to resolve to a real role, policy, or access package.
• Approval Chain: The sequence of reviewers who validate a request before access is granted. Approval chains can improve oversight, but only when each approver has enough context to judge the risk, scope, and business need. Otherwise, the chain documents consent without proving that the entitlement is properly authorised.
• Identity Resolution: Identity resolution is the correlation step that determines whether multiple accounts belong to the same person or accountable role. It combines identifiers, context, and system-specific attributes to reduce false splits and missed matches, which is what makes governance outputs dependable rather than approximate.

What's in the full article

Veza's full article covers the implementation detail this post intentionally leaves for the source:

• Step-by-step ServiceNow configuration for order guides, variables, and requested-item workflows.
• JavaScript script include examples for Veza API calls, error handling, and identity lookups.
• Business rule logic for manager approvals, IT task creation, and access-grant triggers.
• Catalog sync mechanics for creating, updating, and retiring requestable access profiles.

👉 Veza's full article covers the workflow code, catalog sync logic, and provisioning sequence in detail.

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 responsible for identity security strategy or governance in your organisation, it is worth exploring.