Why do IAM changes need ITSM-native approvals instead of pull requests?

Why This Matters for Security Teams

IAM approvals are not just administrative paperwork when the target is a live identity system. The approval itself is evidence that change risk was assessed, segregation of duties was preserved, and the resulting access state can be reconstructed later. Pull requests are useful for code review, but they rarely preserve the operational context needed for systems like Okta, where a change can immediately affect authentication paths, entitlements, and downstream access.

That distinction matters because identity failures are often discovered after access has already been abused. NHI Management Group research shows how quickly credential-related issues can become real incidents, including cases like TruffleNet BEC Attack — Stolen AWS Credentials and Azure Key Vault privilege escalation exposure. For control design, the operational question is not whether a pull request exists, but whether the approval chain can prove who authorized what, when, and against which identity state.

That is why current guidance aligns better with change-management evidence under NIST SP 800-53 Rev 5 Security and Privacy Controls than with source-control workflows alone. In practice, many security teams discover the gap only after a production identity change has already bypassed their audit trail.

How It Works in Practice

The practical goal is to bind three things together: the request, the approval, and the implemented change. In an ITSM-native workflow, the ticket carries the business justification, approver identity, timestamps, affected system, and rollback expectations. The identity platform or automation layer then executes the change and writes back the actual configuration snapshot, creating a record that is useful for audit, incident response, and recovery.

This is especially important for access and policy changes that alter who can authenticate, what they can do, or how recovery behaves. A pull request can describe intent, but it cannot reliably capture runtime context such as emergency access, production impact, compensating controls, or a temporary exception granted to keep a service available. In mature environments, the ticket becomes the control record while the pull request, if used at all, is only supporting evidence.

• Use ITSM as the system of record for approval, not a side channel or chat message.
• Link the change ticket to the exact IAM object, environment, and versioned configuration snapshot.
• Require approvers to be explicit about separation of duties and exception handling.
• Store the post-change state so auditors can compare intended versus actual access.

That approach fits the broader NHI governance pattern documented in the Ultimate Guide to NHIs, where visibility, rotation, and revocation all depend on traceable operational controls. It also supports the control intent in NIST change-management and access-control guidance, where the question is whether a production identity change was authorized and verifiable, not merely reviewed in code. These controls tend to break down when teams treat IAM configuration as static infrastructure code while the underlying identity service is continuously enforcing live access decisions.

Common Variations and Edge Cases

Tighter approval controls often increase operational friction, so organisations need to balance speed against auditability, especially for urgent identity changes. There is no universal standard for every workflow yet, but best practice is evolving toward using the ITSM ticket as the authoritative approval record and letting pull requests remain a development artifact where they add value.

Emergency break-glass changes are the main exception, but they should still be routed through ITSM with after-the-fact review, a clear approver hierarchy, and full evidence capture. The same applies to automated provisioning pipelines: even when the actual change is machine-executed, the authorization should remain anchored to an approved ticket so the organisation can prove why the automation was allowed to act.

Teams also need to distinguish between IAM code deployed through CI/CD and IAM state changes made directly in a vendor console. Where the change affects live entitlement, federation, or recovery controls, the approval must follow the operational control path. Current guidance suggests that a PR-only model is acceptable only when it is not the actual approval mechanism and the ITSM record still holds the authoritative decision trail.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Where does cross-environment agent discovery fit in an IAM programme?
• When should organizations consider updating their IAM frameworks?