Solutions / Conditional Access
Conditional Access deployment, from report-only to enforcement.
Most US Microsoft 365 tenants have Conditional Access policies enabled but sitting in report-only mode, sometimes for years. The reason is always the same: the tenant admin cannot predict what enforcement will break. Identra runs Conditional Access from design through staged enforcement, with policy exclusion management, break-glass isolation, and post-enforcement monitoring so the rollout finishes without service-desk floods.
- Product
- Microsoft Entra Conditional Access
- License requirement
- Entra ID P1 minimum (P2 for risk-based)
- Delivery mode
- Remote-first, US timezone
- Delivery
- Fixed scope, fixed price
01 / What we configure
Four workstreams for a clean CA deployment.
- 01
Policy design
Baseline policies cover MFA for all, block legacy auth, require compliant device for privileged, sign-in risk step-up, session control for high-risk apps. Custom policies added for tenant-specific patterns (partner federation, service accounts, specific compliance overlay).
Baseline policiesCustom policiesSession control - 02
Exclusion set management
Every CA policy has an exclusion group with a documented review cadence and a defensible reason per exclusion. Break-glass accounts isolated in a separate exclusion group with alerting on any use. Service accounts moved to workload identities where possible, or documented as CA-excluded with justification.
Exclusion groupsBreak-glassWorkload identities - 03
Report-only to enforcement staging
Each policy runs in report-only for 2 to 4 weeks. Report data reviewed against expected user impact. Enforcement flip scheduled in graduated waves: privileged users first, then business-critical apps, then all users. User communications drafted for each wave.
Report-onlyGraduated wavesUser comms - 04
Post-enforcement monitoring
Sentinel workbook produces daily CA policy hit rate, exclusion group changes, and any accounts triggering unusual policy patterns. Weekly review meeting with the tenant admin for the first 4 weeks post-enforcement, then handover to internal team.
SentinelDaily reviewHandover
02 / What it looks like
Three CA deployment engagements.
Different starting states, same enforcement-target work.
IT Director at a 500-user professional services firm
Situation. CA has been in report-only for 18 months. Every attempt to flip enforcement has been rolled back after service-desk complaints. Team has stopped trying.
Outcome. Existing policies audited: 3 policies had exclusion sets that had grown to 40+ users over time. Exclusions cleaned, policies redesigned into smaller scoped rules. Enforcement rolled out in 4 waves over 8 weeks with zero rollbacks.
CISO at a US SaaS company
Situation. SOC 2 auditor asked for evidence that MFA is enforced on all administrative access. CA policy exists but is report-only. Auditor did not accept report-only as evidence of enforcement.
Outcome. Privileged users moved to enforced CA first (2-week rollout). Evidence pack from Sentinel showed enforcement dates and hit rate. Auditor accepted enforcement evidence and closed the finding.
Security Officer at a US non-profit
Situation. Board members and volunteers use personal devices to reach the tenant. Some volunteers are elderly and struggle with Authenticator app setup. Team worried about excluding board from CA.
Outcome. App protection policy on personal devices lets volunteers reach Outlook and Teams without device enrolment. Number-matching MFA replaces basic push (simpler UX). Board CA policy tiered so read-only Outlook access has softer MFA than tenant administration.
03 / Frequently asked
What buyers ask first.
- How long does a CA deployment take?
- Typical deployment runs 6 to 10 weeks. Weeks 1 to 2 assess existing policies and identify enforcement gaps. Weeks 3 to 4 design and stage the target policy set in report-only. Weeks 5 to 10 flip enforcement in graduated waves with monitoring for user impact. Complex tenants with many partner federations or service account exclusions can run longer.
- Do we need Entra ID P2?
- Entra ID P1 (included with M365 E3) is enough for policy-based CA. P2 (M365 E5) adds sign-in risk and user risk policies, which use Entra ID Protection signals to trigger step-up MFA or blocked access on anomalous sign-ins. If you have E5, use P2. If E3, the deployment covers the P1 capabilities and calls out the risk-based gaps as an E5 upgrade opportunity.
- What are the most common CA policy failures?
- Five common failure modes. Break-glass accounts subject to CA and locked out during outage. Service accounts subject to CA and failing when the workload identity is not defined. Exclusion groups that grow uncontrolled over time until the policy no longer enforces on the intended users. Legacy authentication left enabled and providing an MFA-bypass path. Policies scoped too broadly (users) rather than narrowly (business-critical apps) so enforcement fails at unexpected places.
- Can you help us with partner and B2B collaboration?
- Yes. Cross-tenant access settings, B2B external collaboration restrictions, and Cross-Tenant Sync configurations are part of a full CA deployment. If your organisation collaborates heavily with partners, the design phase includes partner-scoped CA policies that let partner users reach the specific applications they need without over-provisioning.
- What about the March 2026 Conditional Access modernisation?
- Microsoft is deprecating the Require Approved Client App grant control by March 2026. Any tenant using this grant control must migrate to the newer App Protection Policy grant or the equivalent Intune app protection configuration. Identra CA deployments include the migration if the tenant currently uses the deprecated control.
04 / Related
Where this fits.
Practice
Microsoft Entra consulting
The full Entra practice covering CA plus PIM, ID Protection, access reviews.
Product
Privileged Identity Management
PIM implementation typically paired with a Conditional Access deployment.
Product
Non-human identity security
Service principals need CA assigned directly; group membership does not apply.
Blog
CA defaults: what to block first
Order-of-operations for a CA deployment starting from tenant defaults.