Microsoft Entra ID Conditional Access and PIM as Compliance Evidence
Turn Microsoft Entra ID conditional access and PIM into NIS2 and DORA access-control evidence — exact policies, audit logs, artifacts. For identity leads.
Marc Dekeyser |
Microsoft Entra ID Conditional Access Compliance: Turning Identity Controls into Audit Evidence
Microsoft Entra ID conditional access compliance is the practice of designing access policies and privileged-role workflows so that each one produces a dated, attributable record a regulator accepts as evidence. Conditional Access policies and Privileged Identity Management together answer the access-control clauses of NIS2 Article 21 and DORA — but only if the configuration is built to generate the audit log, not just to enforce the control.
Identity is the control plane that matters most. When a credential is compromised, every downstream control is exposed. NIS2 and DORA both single out access control and authentication for explicit treatment, and both expect you to demonstrate enforcement, not assert it. The gap most organisations carry is that their Conditional Access works but cannot be evidenced, and their administrators hold standing privilege that no review ever touches.
Key takeaways
- Conditional Access policies in Microsoft Entra ID enforce NIS2 Article 21(2)(i) and (j) — but the evidence is the policy export plus sign-in logs, not the policy alone.
- Privileged Identity Management (PIM) replaces permanent Global Administrator assignments with just-in-time activation, approval, and time limits.
- The PIM audit log — who activated which role, who approved, for how long — is the single most useful access-control artifact for a regulator.
- Blocking legacy authentication closes the most common multifactor-authentication bypass; it is a baseline, not an enhancement.
- Access reviews in PIM produce recurring, dated attestation that standing privilege has been re-justified.
How does Microsoft Entra ID conditional access support compliance?
Microsoft Entra ID conditional access supports compliance by enforcing named conditions on every sign-in and recording the result, which gives you both the control and the evidence that the control ran. A Conditional Access policy evaluates signals — user, device, location, risk — and grants, blocks, or challenges access. Each evaluation is logged in the Microsoft Entra ID sign-in logs.
For a regulated organisation, a defensible Conditional Access baseline includes four policies:
Block legacy authentication. Legacy protocols — IMAP, POP, SMTP AUTH, older Exchange ActiveSync — cannot present a multifactor challenge. A policy that blocks them closes the most common path around MFA. This is the first policy to verify and the one most often missing.
Require phishing-resistant multifactor authentication. Conditional Access can require authentication strength, and Microsoft Entra ID now supports a phishing-resistant strength tier — FIDO2 security keys, Windows Hello for Business, certificate-based authentication. SMS and voice are not phishing-resistant. For administrative roles, the phishing-resistant strength should be mandatory.
Require a compliant device. A Conditional Access grant control can require the device to be marked compliant by Microsoft Intune. This ties access to device posture — encryption, patch level, configuration — rather than to credentials alone.
Risk-based access via Microsoft Entra ID Protection. Sign-in risk and user risk signals from Microsoft Entra ID Protection feed Conditional Access. A high sign-in risk can force re-authentication; a high user risk can force a secure password change. This is the adaptive layer NIS2 expects under risk management.
The evidence is not the existence of these policies. It is the export of each policy definition paired with the sign-in logs showing the policy applied and what it did. For the broader posture context, the Microsoft 365 security posture assessment covers the surfaces these policies protect.
Why does Privileged Identity Management eliminate standing privilege?
Privileged Identity Management eliminates standing privilege by making high-value roles activatable on demand rather than permanently assigned, so that an administrator holds elevated rights only for the window they are actually working. PIM converts a permanent Global Administrator into an eligible Global Administrator who must activate the role, often through an approval, for a bounded time.
This changes the risk arithmetic. A permanent Global Administrator assignment is a standing target — compromise that account at any moment and you own the tenant. An eligible assignment under PIM is dormant most of the time. Activation can require multifactor authentication, a justification, an approver, and a maximum duration after which the role deactivates automatically.
The concrete configuration that matters:
| PIM control | What it enforces | Compliance value |
|---|---|---|
| Eligible (not active) assignment | No standing privilege; role must be activated | Removes the always-on attack target |
| Activation MFA + justification | Re-proves identity and records reason at activation | Attributable access record |
| Approval workflow | A second person authorises elevation | Separation of duties evidence |
| Maximum activation duration | Role deactivates automatically | Bounds the exposure window |
| Access reviews | Periodic re-justification of eligibility | Recurring attestation artifact |
The target state for the highest roles — Global Administrator, Privileged Role Administrator, Security Administrator — is zero permanent assignments. Every elevation goes through activation. Microsoft’s own guidance treats standing Global Administrator access as a finding.
What audit artifact does PIM produce?
The audit artifact PIM produces is the activation record: for every privileged elevation, who activated which role, who approved it, the justification given, and the start and end time. This is the cleanest access-control evidence Microsoft Entra ID generates, because it maps one-to-one onto what an auditor asks.
A NIS2 or DORA assessor reviewing privileged access wants to answer three questions. Who can become an administrator? When did they, and why? Who authorised it? The PIM audit log answers all three in a single export. Contrast that with a permanent assignment, where the only honest answer to “when did this person use Global Administrator rights” is “we cannot tell from the role assignment.”
A complete privileged-access evidence package therefore contains: the PIM eligible-assignment inventory (who can elevate to what); the activation history for the review period (who actually did, with justifications and approvers); the access-review completion records (proof eligibility was re-examined); and the count of remaining permanent assignments on privileged roles, with a target of zero.
How do these controls map to NIS2 and DORA?
These controls map directly to the access-control and authentication clauses of both frameworks, and the mapping is specific rather than thematic. NIS2 Article 21(2)(i) addresses access control policies and asset management; Article 21(2)(j) addresses the use of multifactor authentication and secured communications. DORA’s ICT risk-management requirements include strong authentication and least-privilege access for ICT systems supporting critical functions.
| Control | NIS2 Article 21 | DORA |
|---|---|---|
| Block legacy auth + phishing-resistant MFA | 21(2)(j) — multifactor authentication | Strong authentication for critical ICT |
| Conditional Access device compliance | 21(2)(i) — access control | Access management for critical functions |
| Risk-based policies (Entra ID Protection) | 21(2)(a) — risk management | ICT risk identification |
| PIM just-in-time + approval | 21(2)(i) — access control, least privilege | Least-privilege, segregation of duties |
| PIM access reviews | 21(2)(i) — periodic review | Periodic access recertification |
The DORA case is treated in more depth in DORA Article 11 and Azure architecture. The point common to both frameworks: they ask for least privilege and strong authentication, and they ask you to prove it on a recurring basis. Conditional Access and PIM are the Microsoft-native way to both enforce and evidence that.
FAQ
Is Conditional Access enough for NIS2 multifactor authentication requirements? Conditional Access enforcing phishing-resistant authentication strength satisfies the technical requirement of NIS2 Article 21(2)(j), but only if it covers all users and all applications, and only if legacy authentication is also blocked. A policy that exempts service accounts or omits legacy-auth blocking leaves an enforceable bypass.
Does PIM require a specific Microsoft Entra ID licence? Yes. Privileged Identity Management requires Microsoft Entra ID P2, included in Microsoft Entra ID Governance and Microsoft 365 E5. Organisations on lower tiers can assign roles but cannot make them eligible-only with activation, approval, and access reviews — meaning standing privilege cannot be eliminated through PIM on those tiers.
What is the difference between an eligible and an active PIM assignment? An active assignment grants the role’s permissions continuously. An eligible assignment grants nothing until the user activates the role, optionally through approval and multifactor authentication, for a bounded time. Eligible-only assignment for privileged roles is the configuration that removes standing privilege.
How long should PIM activation last? Set the maximum activation duration to the shortest window that fits the work — commonly one to four hours for administrative tasks. A shorter window bounds the exposure if an activated session is compromised, and forces re-justification for extended work, which produces additional audit records.
Where the evidence comes from
Platform Architecture Authority reads the Conditional Access policy set and the PIM configuration through the Microsoft Entra ID APIs, identifies the gaps — legacy authentication still permitted, standing Global Administrator assignments, policies that exempt critical applications — and maps each to the NIS2 and DORA clause it bears on, producing the activation and assignment artifacts described above. It is read-only and generates the remediation policy code for you to review; the judgment about which exemptions are defensible for your operations stays with a senior architect. Conditional Access and PIM are not exotic. The gap is rarely the absence of the feature. It is the absence of the evidence.
Build the policy to produce the log.
