Microsoft Entra Conditional Access Governance in 2026

It is 09:12 on a Tuesday when Maria, the CISO of a fast-growing European fintech, opens a DORA readiness report that should have been routine. Her Microsoft Entra Conditional Access dashboard looks strong. MFA is enforced for administrators. Legacy authentication is blocked. High-risk sign-ins are challenged or denied. Sensitive finance applications require compliant devices. Browser access from unmanaged endpoints is restricted.

Then she reads the auditor’s finding.

“Your Conditional Access rules are technically sound, but they exist in a vacuum. Show us the board-approved policy that mandates these settings. Show us the change record for the rule modified last month. Show us how the high-risk sign-in policy was active during the suspected credential stuffing attack. Show us how this evidence supports ISO 27001, DORA, NIS2 and GDPR.”

The identity team can export configuration. The SOC can show sign-in logs. The compliance manager can point to a policy folder. But nobody can produce one governed evidence story that connects risk, policy, approval, configuration, exceptions, monitoring, incident response, privacy obligations and management review.

That is the Conditional Access governance problem in 2026.

Microsoft Entra Conditional Access is no longer just an identity setting. It is a board-level control system that decides who can access cloud services, under what conditions, from which devices, with which authentication strength, and with what session restrictions. For regulated organizations, those decisions must be explainable, defensible and mapped to obligations under ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST and COBIT 2019.

Conditional Access Is Now an Auditable Control System

Conditional Access sits at the intersection of identity, device posture, application sensitivity, location, sign-in risk, user risk, session behavior and logging. A single policy can require MFA, demand a compliant device, block access from a risky location, restrict downloads from unmanaged browsers, or force reauthentication when risk changes.

That makes it one of the strongest Zero Trust enforcement points in Microsoft cloud environments. It also makes it highly auditable.

Under ISO/IEC 27001:2022, a control is not mature simply because it exists in a portal. The organization must understand its context, assess information security risks, select risk treatments, document the Statement of Applicability, operate controls, monitor effectiveness and improve over time. Relevant clauses include Clause 6.1.2 for risk assessment, Clause 6.1.3 for risk treatment, Clause 7.5 for documented information, Clause 8.1 for operational planning and control, Clause 9.1 for monitoring and Clause 9.3 for management review.

Annex A, aligned with ISO/IEC 27002:2022, gives the practical control language that auditors will recognize. Conditional Access commonly supports:

• 5.15 Access control
• 5.16 Identity management
• 5.17 Authentication information
• 5.18 Access rights
• 8.1 User endpoint devices
• 8.2 Privileged access rights
• 8.3 Information access restriction
• 8.5 Secure authentication
• 8.15 Logging
• 8.16 Monitoring activities

For EU-regulated organizations, the governance burden is even clearer. NIS2 Article 20 places responsibility on management bodies to approve and oversee cybersecurity risk-management measures. NIS2 Article 21 requires appropriate and proportionate technical, operational and organizational measures, including access control, asset management, cyber hygiene, incident handling, supply chain security, effectiveness assessment and multi-factor or continuous authentication where appropriate. NIS2 Article 23 introduces staged significant incident reporting, including an early warning within 24 hours, an incident notification within 72 hours and a final report within one month.

DORA raises similar expectations for financial entities. Article 5 requires an internal governance and control framework. Article 6 requires an ICT risk management framework. Article 9 covers protection and prevention, including access restrictions and identity management practices. Articles 10, 11, 17, 18 and 19 connect detection, response, recovery, ICT incident management, classification and reporting. Since DORA applies from 17 January 2025, financial entities should treat Conditional Access as part of operational resilience evidence, not just identity hardening.

GDPR adds the privacy lens. If Conditional Access protects systems that process personal data, it supports Article 5 accountability principles, Article 24 controller responsibility, Article 25 data protection by design and Article 32 security of processing. If unauthorized access is suspected, Conditional Access logs may become part of breach assessment and notification evidence.

The mistake is treating these as separate audit requests. The mature approach is one Conditional Access governance model that can be sliced by framework, regulator, customer or board audience.

Configuration Is Not Governance

Most organizations can answer the question, “What is configured?” Fewer can answer the harder questions:

• Why is this Conditional Access policy configured this way?
• Which risk scenario does it treat?
• Which policy clause requires it?
• Who approved the change?
• Which users, applications and devices are excluded?
• How is it tested?
• What logs prove it worked?
• How often is it reviewed?
• What happens when it fails?

This is where audit findings usually appear. Policies exist but are not linked to Microsoft Entra settings. Device compliance is owned by IT operations but not mapped to access control risk. Sign-in risk policies are enabled without documented thresholds or escalation rules. Session restrictions are configured but never tested from unmanaged devices. Logs are retained but not curated into audit evidence.

Clarysec treats this as a traceability problem. Every Conditional Access decision should connect policy, risk, control, configuration, evidence and review.

The SME Cloud Usage Policy-sme Cloud Usage Policy-sme - SME states:

Multi-factor authentication (MFA) for administrative and user accounts

From section “Policy Implementation Requirements”, policy clause 6.2.2.

That clause is the mandate. The Conditional Access rule is the enforcement. The sign-in log is the evidence. The review record proves oversight.

The SME Network Security Policy-sme Network Security Policy-sme - SME adds the endpoint posture requirement:

Systems without up-to-date antivirus, patches, or an acceptable device posture must be blocked or quarantined

From section “Policy Implementation Requirements”, policy clause 6.4.3.

In Microsoft Entra terms, this can become “require compliant device,” “block unsupported platforms,” “restrict unmanaged browser sessions,” or “deny access to high-risk applications from unknown devices.” But the control is not complete until the organization can prove scope, approval, testing, exceptions and monitoring.

Build the Governance Foundation Before the Rule Set

A strong Conditional Access program starts outside the Entra portal. It starts with the ISMS, risk register, access control policy, cloud usage policy, SoA and evidence model.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint gives a practical sequence. In the Risk Management phase, Step 13, Risk Treatment Planning and Statement of Applicability, it instructs organizations to connect controls to risks and regulatory drivers:

Cross-reference regulations: If certain controls are implemented specifically to comply with GDPR, NIS2, or DORA, you can note that in either the Risk Register (as part of risk impact justification) or in the SoA notes.

For Conditional Access, that changes the evidence story. Instead of saying, “We enabled MFA,” the organization can say:

• Risk scenario: Compromised user credentials allow unauthorized access to customer data in Microsoft 365 and finance SaaS.
• Risk owner: Head of IT Security.
• Treatment: Entra Conditional Access requires strong MFA for privileged roles, MFA for users, sign-in risk blocking, compliant devices for sensitive applications and session restrictions for unmanaged endpoints.
• ISO/IEC 27002:2022 mapping: 5.15, 5.16, 5.17, 5.18, 8.1, 8.2, 8.3, 8.5, 8.15 and 8.16.
• Regulatory mapping: NIS2 Articles 20, 21 and 23, DORA Articles 5, 6, 9, 10, 17 and 18, GDPR Articles 24, 25, 32 and 33.
• Evidence: Policy approval, Conditional Access export, change ticket, test results, sign-in logs, device compliance reports, exception register, SOC tickets and management review minutes.

The Zenith Blueprint also explains in the Controls in Action phase, Step 19, why endpoint posture belongs in the access decision:

Access to information via endpoints must be context-aware. For example, does the device meet minimum security standards before accessing company resources? Has it recently passed a malware scan? Is it connecting from an unusual location or network? Integrating with Zero Trust principles, endpoint posture can feed into conditional access, denying entry until the device proves it’s safe.

That is the core governance principle. Conditional Access should be risk-based, context-aware and evidence-producing.

Map Conditional Access Decisions to Control Objectives

A mature program defines standard access decisions, then maps each one to governance intent and evidence. This prevents policy sprawl and makes audit conversations easier.

The Enterprise Cloud Usage Policy Cloud Usage Policy supports central identity integration:

Single Sign-On (SSO) integration with the organization’s IdP is required to ensure authentication consistency.

From section “Policy Implementation Requirements”, policy clause 6.2.4.

The Enterprise User Account and Privilege Management Policy User Account and Privilege Management Policy makes monitoring explicit:

The use of Single Sign-On (SSO) systems must be integrated with central identity providers (e.g., Active Directory (AD), Azure AD) and monitored for anomalous login activity.

From section “Policy Implementation Requirements”, policy clause 6.3.4.

Together, these clauses require more than SSO. They require central identity architecture, consistent authentication, anomalous login monitoring and evidence that access decisions are reviewed.

Device Compliance: The Control Auditors Can Test

Device compliance is one of the easiest areas to overstate. A dashboard might show 92 percent compliant devices, but an auditor will ask whether the rule applies to the applications that matter, whether personal devices are allowed, whether unsupported platforms are blocked, and whether exceptions are approved.

The Enterprise Remote Work Policy Remote Work Policy sets the approval baseline:

BYOD devices must be explicitly approved and:

From section “Governance Requirements”, policy clause 5.2.2.

That short sentence matters. BYOD is not just a technical state. It is a governance decision. In Conditional Access, it should translate into device ownership rules, minimum compliance baselines, encryption requirements, patch and malware protection checks, mobile app protection, contractor handling and exception review.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls maps ISO/IEC 27002:2022 control 5.15 Access control as preventive, protecting confidentiality, integrity and availability in the identity and access management operational capability. It also connects access control to user endpoint devices because unmanaged laptops, mobiles and desktops can undermine centralized access enforcement.

A practical quarterly Conditional Access Device Evidence Pack should include:

• Approved device compliance baseline.
• Conditional Access policies requiring compliant devices.
• Applications protected by those policies.
• Export of excluded users, groups, applications and platforms.
• Non-compliant device trend report.
• Sample blocked sign-in logs for non-compliant devices.
• Exception register with owner, reason, expiry date and risk acceptance.
• Management review record.

This evidence pack supports ISO/IEC 27001:2022 operational control, NIS2 cyber hygiene, DORA protection and prevention, and GDPR accountability.

Sign-In Risk: Detection Must Become Decision Evidence

Risk-based Conditional Access is where identity detection becomes access governance. Microsoft Entra can evaluate signals such as unfamiliar sign-in properties, anonymous IP addresses, impossible travel and leaked credentials. But auditors will not accept “risk policy enabled” as the final answer. They will ask why thresholds were selected, who reviews risky events and when a high-risk sign-in becomes an incident.

The SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME defines a minimum logging requirement:

Authentication logs: Successful and failed login attempts, session duration, MFA usage

From section “Governance Requirements”, policy clause 5.4.2.

The Enterprise Logging and Monitoring Policy Logging and Monitoring Policy broadens the expected event set:

Event types to be captured (e.g., logins, access failures, configuration changes, administrative commands, malware detection)

From section “Governance Requirements”, policy clause 5.1.1.

For Conditional Access, useful evidence should include successful sign-ins, failed sign-ins, Conditional Access policy result, MFA method, sign-in risk, user risk, device compliance state, application accessed, location, client application, session control result, policy change history and administrative actions.

Zenith Controls maps ISO/IEC 27002:2022 control 8.16 Monitoring activities as detective and corrective, associated with Detect and Respond concepts. It connects monitoring to logging, event assessment, threat intelligence, supplier monitoring and incident management. It also maps monitoring activities to GDPR Articles 32 and 33, NIS2 incident monitoring and reporting, DORA ICT incident tracking, NIST continuous monitoring and COBIT security monitoring.

A high-risk sign-in blocked by Conditional Access is therefore not just a security win. It is evidence that preventive, detective and response processes are connected.

Session Controls: The Link Between Access and Data Protection

Pre-access decisions are not enough. Once a user is authenticated, session controls determine how much exposure remains. This is especially important for unmanaged devices, contractors, remote work, shared terminals, risky locations and applications processing personal data.

The SME Application Security Requirements Policy-sme Application Security Requirements Policy-sme - SME states:

Session Management: Session data must expire after 15 minutes of inactivity and include timeout warnings where applicable.

From section “Policy Implementation Requirements”, policy clause 6.1.1.3.

In Microsoft Entra governance, this can map to sign-in frequency, persistent browser session restrictions, Conditional Access App Control, app-enforced restrictions, download blocking, reauthentication after risk changes and sensitivity-based session limitations.

Session controls support ISO/IEC 27002:2022 control 8.3 Information access restriction and 8.5 Secure authentication. They also support GDPR Article 32 by reducing unauthorized viewing, downloading or persistence of access to personal data. For DORA, session restrictions help limit exposure in ICT systems and support detection and response. For NIS2, they are proportionate access control and cyber hygiene measures.

The evidence should explain why the session control exists. For example, “block download from unmanaged devices for HR and finance applications” should map to personal data leakage, endpoint compromise and loss of confidentiality. Evidence should include configuration, application scope, test sign-ins from managed and unmanaged devices, logs showing restrictions and approval records.

Create a Conditional Access Control Register

A Conditional Access Control Register is the operational bridge between the risk register, Statement of Applicability and Microsoft Entra configuration. It does not replace those documents. It makes them usable.

Use a five-step review cycle:

1. Confirm scope: Identify cloud applications processing regulated, financial, operational or personal data.
2. Map policies to risks: Link each Conditional Access policy to at least one risk scenario and one risk owner.
3. Validate exclusions: Export excluded users, roles, apps, groups, locations and devices. Each exclusion needs an owner, reason, approval and expiry.
4. Test enforcement: Use test accounts to verify MFA, device compliance, risk blocking, legacy authentication blocking and session restrictions.
5. Package evidence: Store exports, screenshots, logs and approvals with metadata.

The SME Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme - SME is critical for evidence integrity:

Metadata (e.g., who collected it, when, and from which system) must be documented.

From section “Policy Implementation Requirements”, policy clause 6.2.3.

Screenshots without source, date, collector and system context are weak evidence. Conditional Access exports, sign-in logs and review reports should be treated as controlled audit records.

Cross-Compliance Mapping for Conditional Access Evidence

The value of Conditional Access is that one control set can satisfy several audit lenses when properly governed.

Zenith Controls also maps 5.15 Access control to GDPR Article 32, NIS2 Article 21(2)(i), DORA access governance concepts, NIST SP 800-53 access control families and COBIT 2019 DSS06.04. It maps 8.5 Secure authentication to GDPR Articles 5, 24, 25 and 32, NIS2 cybersecurity risk management, DORA ICT risk management, NIST identification and authentication, and COBIT identity and logical access.

The lesson is simple. Frameworks use different language, but they expect the same assurance pattern: the right users, from acceptable contexts, using strong authentication, through governed sessions, with logs proving what happened.

How Auditors Will Examine Conditional Access

An ISO/IEC 27001:2022 auditor will start with the ISMS. They will ask whether Conditional Access is in scope, which risks it treats, how it appears in the SoA, how policies are approved, how changes are controlled and whether evidence proves operating effectiveness. Expect sampling of privileged users, sensitive applications, exclusions and recent policy changes.

A DORA or NIS2 auditor will focus on operational resilience, management accountability and risk. They may ask how access controls protect critical or important functions, how the board oversees identity risk, how high-risk sign-ins are triaged, and whether access failures feed incident classification or reporting decisions.

A GDPR-focused auditor will care about personal data. They may ask how HR, finance or customer data is protected from unmanaged devices, how session controls reduce unauthorized viewing, how access is limited to authorized users and how logs support breach assessment.

A COBIT 2019 reviewer will look for governance practices, ownership, metrics, repeatability, performance monitoring and improvement. A NIST-oriented assessor will compare identity, authentication, authorization, monitoring and response outcomes against technical evidence.

The Enterprise Access Control Policy Access Control Policy sets the tone for privileged access:

Administrative access must be tightly controlled through:

From section “Governance Requirements”, policy clause 5.4.1.

Your Microsoft Entra evidence must complete that sentence operationally. Which roles are privileged? Which require phishing-resistant or strong MFA? Which are eligible through privileged identity management? Which accounts are break-glass? Which are excluded from policies? Who reviews them? Where are alerts sent?

Board Metrics for Conditional Access Governance

Because NIS2 and DORA emphasize management accountability, Conditional Access reporting should be board-readable. Avoid reporting only policy names. Report risk posture and control performance.

Useful metrics include:

• Percentage of privileged accounts protected by strong MFA.
• Number of Conditional Access exclusions by risk tier.
• Number of high-risk sign-ins blocked, challenged or allowed.
• Percentage of sensitive application access requiring compliant devices.
• Number of unmanaged device sessions to regulated applications.
• Time to triage high-risk sign-in events.
• Number of Conditional Access policy changes in the quarter.
• Number of expired, renewed and overdue exceptions.
• Coverage of authentication, session and policy change logging.
• Failed test cases from quarterly Conditional Access validation.

These metrics turn identity configuration into oversight evidence. They also help management bodies demonstrate approval, review, resourcing and continual improvement.

Common Findings to Eliminate Before the Audit

Conditional Access findings usually come from governance weakness, not technology failure. The most common issues include:

• Break-glass accounts are excluded but not monitored.
• Policies are named inconsistently and lack owners.
• Sensitive applications are missing from device compliance rules.
• Guest users and external collaborators bypass standard controls.
• Service accounts and workload identities are not separately governed.
• Sign-in risk detections are not triaged or linked to incidents.
• Session controls are never tested from unmanaged devices.
• Policy changes are made directly in production without change records.
• Exclusions are permanent, undocumented or verbally approved.
• Logs are retained but not reviewed.
• Evidence lacks metadata, source context or chain of custody.

A 2026-ready target state has management-approved access governance, risk-based Conditional Access design, explicit ISO/IEC 27001:2022 and ISO/IEC 27002:2022 mapping, documented NIS2, DORA and GDPR support, strong MFA by role and risk, device compliance for sensitive access, session restrictions for unmanaged contexts, monitored authentication and policy changes, an exception lifecycle, quarterly testing and management reporting.

Turn Microsoft Entra Into Audit-Ready Evidence

Your Conditional Access policies are already making security decisions every minute. The question is whether those decisions are governed, risk-based, monitored and mapped to the obligations your auditors and regulators care about.

Start with Zenith Blueprint Zenith Blueprint, especially Step 13, to connect Conditional Access policies to risks, treatments, the Statement of Applicability and regulatory notes. Use Zenith Controls Zenith Controls to map access control, secure authentication, endpoint posture, logging and monitoring across ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST and COBIT 2019.

Then align your internal requirements with Clarysec policies, including Cloud Usage Policy-sme, Network Security Policy-sme, Logging and Monitoring Policy-sme, Audit and Compliance Monitoring Policy-sme, Application Security Requirements Policy-sme, Cloud Usage Policy, User Account and Privilege Management Policy, Remote Work Policy, Access Control Policy and Logging and Monitoring Policy.

Clarysec helps you turn Microsoft Entra Conditional Access from a collection of settings into an enforceable, measurable and audit-ready control system. Download the relevant Clarysec toolkits, request a policy mapping review, or book an assessment to see whether your Conditional Access evidence can withstand ISO 27001, NIS2, DORA and GDPR scrutiny.