Teams should move access changes into a lifecycle workflow that records request, approval, provisioning, review and removal as one controlled process. Entra can remain the identity base, but the governance logic must extend into downstream applications and service operations. Otherwise, lifecycle controls stay partial and exceptions keep accumulating.
Why manual access changes undermine an otherwise sound Entra foundation
When Entra is the identity source but access changes are still handled by tickets, spreadsheets, or ad hoc admin action, the organisation has split identity from governance. The directory can prove who the user is, but it does not control whether access is granted, reviewed, or removed consistently across the rest of the estate. That gap is where lifecycle drift starts.
The practical issue is not the identity platform itself, but the handoff after authentication and directory state. If downstream apps, shared platforms, and service operations still rely on manual steps, then the access model becomes only partially automated. Teams end up with delayed provisioning, inconsistent approvals, and removal that is easy to forget when people move roles or leave.
That means the right question is not whether Entra is in place. It is whether the access process is governed end to end, from request through provisioning to review and deprovisioning, with a single record of the decision.
What a complete lifecycle workflow needs to cover
A usable lifecycle workflow ties together the decision, the change, and the evidence. Request, approval, provisioning, review, and removal should be treated as one controlled process rather than separate operational tasks. That is what turns identity from a directory record into a governed access model.
This workflow also has to extend beyond human joiner-mover-leaver events. Where applications, platform roles, or operational accounts are involved, the same control logic should govern entitlement changes, not just interactive user access. The important point is that access state must be observable and reversible, regardless of whether the target is a SaaS app, an internal system, or a privileged operation.
- Record the business reason for the access change.
- Bind approval to the entitlement being changed, not just the person.
- Provision through an auditable workflow, not manual console edits.
- Review access on a fixed cadence so exceptions do not become permanent.
- Remove access automatically or through a tracked closure step.
For teams building this out, IAM and IGA Basics is the most direct conceptual anchor for the difference between identity management and access governance. For lifecycle mechanics specifically, NHI Lifecycle Management Guide usefully shows why provisioning, review, and offboarding need to be designed as one chain rather than isolated tasks.
Where manual change handling usually breaks down
Manual access changes usually fail in the same ways: approvals are not retained, changes are made outside the normal workflow, or removal lags behind role change and termination. Once that happens, the organisation accumulates exceptions, and those exceptions are often the hardest items to discover later because they were created outside normal control points.
The biggest operational weakness is that manual steps encourage local fixes. A team may satisfy an urgent request quickly, but the result is often a permission that bypasses review logic, a shared admin action that no one owns, or a service entitlement that is never revisited. Over time, this creates a hidden inventory of access that the identity platform alone cannot explain.
That is why Top 10 NHI Issues is still relevant even when the immediate problem looks like human access administration: it highlights the pattern of stale access, excessive permissions, and weak offboarding that emerges when governance does not keep pace with entitlement sprawl. The same logic also appears in Ultimate Guide to NHIs, Regulatory and Audit Perspectives, where access review and auditability are part of the control story, not an afterthought.
Risk and Threat Considerations
Manual access changes create a predictable exposure pattern: excess privilege persists longer, removals lag behind HR or operational events, and exceptions become difficult to detect. That increases both accidental overexposure and the blast radius of any compromised account or misused admin path.
Failure mechanism: The control fails when entitlement changes are executed outside the governed workflow, because the organisation loses a reliable trail for approval, implementation, review, and revocation. At that point, access drift accumulates faster than it can be recertified.
Impact: Unnecessary access remains active, offboarding becomes incomplete, and investigators may not be able to prove who approved or removed a permission. In a compromise, that same gap can preserve attacker access long after the original user event should have closed it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Manual access changes and revocation are core account lifecycle controls. |
| IA-5 — Authenticator Management | Lifecycle governance depends on managing credentials and related access material. | |
| AC-6 — Least Privilege | Unreviewed manual changes commonly create excessive access beyond business need. | |
| Recommendation — Automate account and entitlement changes through a controlled lifecycle workflow. Track issuance, rotation, and revocation of access material within the workflow. Limit each entitlement change to the minimum privilege required. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must be provisioned, reviewed, and removed under formal governance. |
| A.8.2 — Privileged access rights | Manual admin changes often leave privileged access outside controlled review. | |
| Recommendation — Define access-rights ownership, review cadence, and removal obligations. Subject privileged entitlements to approval and periodic recertification. | ||
Practitioner Guidance
What to prioritise: Make the first remediation step an access inventory that shows where Entra is authoritative and where approval, provisioning, and removal still happen elsewhere. That reveals whether the gap is process design, application integration, or simple operational debt.
What to verify: Check that every access change leaves evidence of request, approval, implementation, and removal or recertification. If any one of those states is missing, the workflow is still partial even if the directory itself is well managed.
Common mistake: Do not treat a successful sign-in or a current group membership as proof that lifecycle control exists. The control is working only when access changes can be traced and reversed without relying on tribal knowledge.
Practitioner takeaway: Entra can be the identity system of record, but governance must own the full entitlement lifecycle, otherwise manual changes will keep turning into untracked access and lingering exceptions.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- How should security teams govern access when identity data changes faster than review cycles?