A Conditional Access policy can show as enabled while an administrator still authenticates through an unintended path. The engineering task is to establish which identities can reach which resources, under what conditions, and whether the evidence matches the intended policy.
This guide is a reference implementation for a Microsoft 365 tenant with managed endpoints and Entra ID. It provides a deployment sequence and acceptance criteria, not a claim that a particular customer environment has passed them. Examples must be adapted and tested before enforcement.
1. Establish the baseline and dependencies
Export existing Conditional Access policies, role assignments, authentication methods, application owners, and exceptions. Record policy IDs as well as names. Identify interactive users, guest users, emergency administrators, and service principals separately. User Conditional Access policies are not a substitute for controls over application identities.
Confirm entitlement before design: Conditional Access generally requires Entra ID P1; risk-based capabilities require additional licensing. PIM requires the applicable P2 or Identity Governance entitlement. Microsoft 365 bundles differ. Avoid proposing a control that the tenant cannot license or operate. See Microsoft’s Conditional Access overview.
Review a representative business cycle, including unattended reporting, scheduled mail, and month-end jobs. A clean afternoon of sign-in logs is weak evidence that legacy dependencies are gone. Export logs to an approved destination before the tenant’s retention window expires, and assign an owner to each discovered dependency.
2. Prove emergency access before enforcing restrictions
Maintain at least two cloud-only emergency accounts with independent phishing-resistant credentials and permanent active Global Administrator assignments. Exclude them from Conditional Access policies that could block or restrict emergency sign-in, and alert on every use. An exclusion does not remove platform-level mandatory MFA requirements. Store credentials separately from everyday administration and test the recovery path regularly. Follow Microsoft’s emergency access guidance.
Record an actual exercise: who retrieved the credential, which workstation was used, whether the alert arrived, and whether a harmless administrative action succeeded. Keep a known-good administrator session during rollout, but do not rely on that session as your only rollback route.
3. Block legacy authentication through a staged policy
- In Entra Conditional Access, create a policy named
CA-001-Block-Legacy-Authentication. - Target all users, excluding the documented emergency accounts. Target all resources.
- Configure client-app conditions for Exchange ActiveSync clients and Other clients, and set the grant control to Block access.
- Start in report-only. Review interactive and non-interactive sign-ins, identify affected owners, and replace dependencies with supported modern authentication.
- Run approved negative tests against a service that still accepts the relevant protocol. Confirm the intended policy decision in the sign-in record, then enforce in a planned change window.
This sequence follows Microsoft’s legacy-authentication policy procedure. Protocol availability and authentication method are different questions: do not assume that all SMTP or IMAP traffic uses Basic authentication. Check the client and resource configuration. A retired protocol may fail before Conditional Access evaluates it, which does not prove your policy worked.
A temporary exception needs an owner, expiry, replacement plan, and compensating restriction. An indefinitely excluded service account becomes a permanent bypass. Where Security Defaults is active, plan its transition to a complete equivalent Conditional Access baseline; do not simply disable it to create one isolated policy.
4. Separate routine work from privileged access
Use dedicated administrative identities with the smallest necessary directory roles. Keep email and normal browsing off those identities. Require an appropriate phishing-resistant authentication strength for privileged access, and validate enrollment before enforcement. Device compliance should be introduced as a separately tested control so an enrollment failure does not simultaneously break every recovery path.
For routine privileged work, make roles eligible through PIM where licensed. Define activation duration, justification, approval for sensitive roles, and an available approver. Do not make emergency access depend on approval by the same unavailable administrators it must recover. Review service principals, application consent, secrets, and certificates independently; a privileged app credential can bypass the human activation workflow.
Our proposed acceptance condition is explicit: an ordinary user account cannot perform the selected administrative operation; an eligible administrator can do it only after the approved activation and authentication sequence; an expired activation removes the relevant role access once authorization and token behavior have been accounted for.
5. Validate the combined policy outcome
Conditional Access is not a first-match firewall rule list. Assess the effective combination of applicable policies. Use What If to inspect targeting, report-only logs to assess impact, and controlled sign-ins to verify real outcomes. Report-only success is not enforcement evidence.
- Managed administrator with approved strong authentication: expected success.
- Administrator using an insufficient authentication method: expected challenge or denial.
- Known legacy client: expected block, with the responsible policy identified.
- Emergency identity: tested access and alert delivery.
- Guest and unattended application: documented result consistent with their separate scope.
Keep the test timestamp, user object ID, application, client type, device state, correlation ID, and policy outcome. Redact personal data before sharing evidence. Investigate unexpected successes as seriously as failures.
6. Operate the baseline as a controlled configuration
Maintain a change register containing policy exports, approver, pilot cohort, test results, and rollback instructions. Roll back the specific changed policy where possible instead of disabling the entire security baseline. After stabilisation, review new exceptions, privileged assignments, authentication registrations, and application credentials on a defined cadence.
The deliverable is a repeatable access decision with an evidence trail. For a scoped tenant review, see StackLocked Microsoft 365 Security. To extend identity boundaries into workloads, continue with our AWS and Azure zero-trust engineering guide.