Should teams treat promotions as access reviews or as provisioning events?

Why This Matters for Security Teams

Promotions are not just HR milestones. They are identity state changes that can quietly expand access if teams only add new entitlements and leave the old ones in place. That is especially risky for NHIs, where service accounts, tokens, and automation roles often outlive the business context that created them. The Ultimate Guide to NHIs makes the broader point that excessive privilege remains one of the most common governance failures, and OWASP calls out over-privileged identity patterns in the OWASP Non-Human Identity Top 10.

The operational mistake is assuming a promotion is a clean replacement event. In real environments, it is usually an overlap event: the person or workload keeps inherited access while new access is added, then downstream systems never receive a complete removal signal. That creates accumulation, audit noise, and avoidable blast radius. NHI Mgmt Group’s research shows why this matters in practice: 97% of NHIs carry excessive privileges, which means privilege sprawl is already the default rather than the exception. In practice, many security teams encounter access drift only after a promotion, transfer, or incident review has already exposed the mismatch.

How It Works in Practice

The safest approach is to treat promotion workflows as two linked controls: provisioning for the new role and review for the old one. The provisioning step grants only what the new role requires. The review step removes access that no longer fits, including inherited group membership, stale application roles, legacy approvals, and any secret or token permissions attached to the previous position. This aligns with the lifecycle model described in the NHI Lifecycle Management Guide, where lifecycle transitions are moments to re-evaluate entitlement, not just expand it.

For NHIs, the same logic applies to automation accounts, pipelines, and agentic workloads. Current guidance suggests using policy as code to determine what the new role should receive at runtime, rather than relying on static templates alone. That means tying promotion events to:

• role mapping that defines the minimum new entitlements;
• automatic removal of prior-role access where no longer justified;
• credential and secret rotation when the access context changes;
• approval logs that distinguish provisioning from recertification;
• continuous checks against effective permissions, not just assigned permissions.

This is also consistent with the lifecycle and offboarding emphasis in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, because promotion is essentially a partial offboarding from the old access profile. Teams should integrate IAM, PAM, and secrets management so that elevated access is time-bound and revocation is automatic where possible. These controls tend to break down in federated environments with multiple HR, IAM, and application owners because no single system owns the complete entitlement graph.

Common Variations and Edge Cases

Tighter promotion controls often increase administrative overhead, requiring organisations to balance speed against the risk of privilege accumulation. That tradeoff is real, especially in fast-moving engineering, operations, and platform teams where promotions also trigger on-call changes, repository access, production access, and NHI ownership changes.

There is no universal standard for this yet, but current guidance suggests treating promotions differently by identity type. For humans, the emphasis is recertification plus privilege subtraction. For NHIs, it is often closer to a controlled reissuance event, because the workload may need new secrets, new scopes, or new trust boundaries after a role change. Promotions that cross business units, production tiers, or data sensitivity levels should trigger a deeper review than lateral promotions. The Top 10 NHI Issues is a useful reminder that stale credentials and excessive privilege usually travel together, so the safest promotion process pairs access expansion with explicit removal and rotation.

Edge cases include temporary acting roles, emergency promotions, and reorganisations where access must be restored quickly. In those cases, best practice is evolving toward just-in-time access with a defined expiry and a mandatory post-event review. That reduces the chance that emergency privileges become permanent. Promotions become a provisioning-only event only when there is no meaningful access inheritance to remove, which is rare in mature environments.

Related resources from NHI Mgmt Group

• How do teams know whether provisioning and access reviews are working?
• How should security teams run access reviews for non-human identities?
• What breaks when healthcare teams rely on provisioning-time access for AI systems touching ePHI?
• How should security teams make access reviews cover the real application estate?