Permission review checks who should have access, while drift review checks whether the live platform still matches the approved security state. In Microsoft 365, both matter because delegated access and authentication settings can become risky even when formal roles look correct. Teams need both views to avoid false confidence.
Why Reviewing Permissions Is Different From Reviewing Drift
Permissions review asks whether the right people, roles, or service paths still have access. Drift review asks whether the live environment still matches the approved baseline, including the settings that shape authentication, delegation, and other control behaviour. The difference matters because access can look acceptable on paper while the actual platform has silently moved away from the intended security state.
Permissions are about entitlement, drift is about state. A permissions review can miss a risky configuration that broadens access indirectly, while a drift review can miss the fact that a formally approved role is too broad for the job. In practice, the two checks answer different questions and protect against different failure modes.
For Microsoft 365 and similar platforms, this distinction is especially important because delegated access, authentication settings, conditional access, and admin configuration can change without a clean role change. A team that only audits permissions can still inherit exposure from an unsafe tenant setting or from a control that no longer matches the approved design.
What Each Review Actually Tests
A permissions review is essentially a who-can-do-what exercise. It focuses on assigned roles, group membership, app consent, delegated privileges, and whether each access grant is justified by business need. The output should tell you which identities have access, whether that access is still required, and whether the access level is proportionate to the job.
A drift review is a did-the-system-stay-as-approved exercise. It compares the current configuration to the intended security baseline and looks for changes in policy, authentication, delegation, logging, or protection settings that were not intended or not governed. The key question is not who has a role, but whether the platform still behaves the way the organisation expects.
That distinction is why the same environment needs both lenses. A clean access list does not prove the tenant is well configured, and a compliant baseline does not prove the right accounts have the right access. You need both to establish whether the control design and the live implementation still match.
Why Teams Need Both Views in Practice
In mature operations, permissions review and drift review are complementary controls, not interchangeable steps. Permissions review helps reduce excess privilege and stale access. Drift review helps catch silent control weakening, such as authentication changes, policy relaxation, or delegated settings that expand the blast radius even when individual assignments still look reasonable.
For identity-heavy environments, this is where posture management becomes more valuable than one-off audit evidence. Identity Security Posture Management (ISPM) Guide is useful here because it treats identity configuration, access hygiene, and posture drift as a continuous problem rather than a periodic checkbox.
When drift is present, a permissions review may create false confidence because it validates the wrong layer. When permissions are excessive, a drift review may still show a technically approved configuration even though the access model is too generous. The practical lesson is that one review looks at entitlement integrity, the other looks at configuration integrity.
Risk and Threat Considerations
Risk arises when organisations assume that clean roles mean safe access, or that an approved baseline means the environment is still controlled. That gap can hide overprivilege, weakened authentication, and delegated access that expands silently over time. In Microsoft 365-style platforms, the most dangerous failures are often the ones that preserve a formal appearance of control while changing the actual blast radius.
Failure mechanism: Access review validates assignments, but configuration drift changes the enforcement layer, so the environment can remain overexposed even after a successful entitlement audit.
Impact: Teams can miss unauthorized access paths, misjudge the security posture, and delay remediation until a compromise or policy failure is already in progress.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Drift review compares live settings to an approved security baseline. |
| AC-6 — Least Privilege | Permission review exists to find excess access and reduce privilege. | |
| IA-5 — Authenticator Management | The answer mentions authentication settings that can drift into risk. | |
| Recommendation — Compare live tenant settings to an approved baseline and investigate unauthorized changes. Review assigned access and remove permissions that exceed job need. Validate authenticator settings and rotate or revoke weak or stale credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The question contrasts entitlement review with access enforcement and authentication state. |
| ID.IM-01 — Improvements are identified and acted upon | Drift review identifies security state changes that must be corrected. | |
| Recommendation — Review identity and access controls separately from configuration baselines. Track configuration drift and correct deviations from the approved state. | ||
Practitioner Guidance
What to verify: Treat the two reviews as separate evidence streams. Confirm that your access review covers direct and delegated permissions, while your drift review compares live policy, authentication, and tenant settings against an approved baseline. If one process is used to stand in for the other, the control design is incomplete.
Common mistake: Do not use a clean permissions report as proof that the platform is secure. The most common miss is assuming that no one has excessive access, when in fact the authentication or delegation layer has drifted into a weaker state.
Practitioner takeaway: Permission review answers whether access was granted correctly, while drift review answers whether the environment still enforces the intended security model; strong teams run both because either one can be green while risk is already growing.
Related resources from NHI Mgmt Group
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between attack surface management and NHI governance?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?