The operating principle
A policy is only as good as its targeting and recovery path
Evaluate the affected identities, exclusions and emergency access before enforcing. Record the observed sign-in results in a pilot and assign ongoing responsibility for changes.
Choose the correct baseline before writing custom policy
Inventory current Security Defaults status, Conditional Access licences, privileged roles, applications and existing authentication controls. The two approaches should not be treated as interchangeable toggles; Microsoft notes that organisations moving from Security Defaults to Conditional Access must protect their environment immediately with the replacement configuration.
Write the business requirement in plain language: for example, require an additional authentication factor for a specific population or restrict sensitive administration to compliant devices. Determine which users and apps are within scope, the exceptions for service identities, and the customer who has authority to approve them.
| Identity scenario | Question to answer | Evidence |
|---|---|---|
| Standard employee access | Which applications and authentication rules apply? | Test user sign-in and resulting policy |
| Privileged administrator | Is stronger control and monitoring required? | Privileged sign-in test and role audit |
| Emergency access | Can a customer-owned account recover from lockout? | Protected account test and custodian |
| Third-party integration | Could noninteractive sign-in be interrupted? | Application owner and service principal review |
Use a controlled testing and rollout sequence
Start by assessing existing policies and sign-in logs, then test the proposed changes in report-only or a limited pilot when Microsoft supports that approach. Use a representative group including normal employees, remote workers, privileged administrators and critical applications. Record unexpected policy evaluation results and obtain approval before broad enforcement.
Where customer licences do not support a planned feature, document that limitation rather than recommending an inaccessible toggle. If changing Security Defaults, define a safe replacement and an emergency recovery path before the transition. Never create a blanket exemption purely to get past a failing test.
Documented administration controls
- Current licence and identity baselines recorded
- Customer change approver identified
- Pilot population and applications selected
- Emergency administrator access independently controlled
- Rollback/recovery plan documented
Make exceptions temporary and reviewable
Conditional Access exclusions may be needed for documented emergencies or technical constraints, but every exception should have an owner, reason, expiry or review date, and compensating control. An undocumented permanent exclusion for a senior account can undermine the entire policy. Treat application registrations and automation identities as separately managed risks.
Keep change records containing policy identity, old and new configuration, approver, test accounts and actual sign-in results. Tie policy changes to service tickets and avoid forwarding confidential sign-in detail into general contact forms.
Operational acceptance and handover
After rollout, confirm that intended users can access the required services and that disallowed paths fail as expected. Sample ordinary devices and supported client applications, then review the sign-in logs for unexpected outages. A green policy screen is not a complete user acceptance test.
The customer should retain full ownership of tenant access and emergency accounts. A managed provider can operate approved changes, monitor exceptions and present a periodic review, but the business must approve its own security policy and understand the consequences of a service-provider change.
Documented administration controls
- Observed results captured for allowed and blocked journeys
- Privileged roles reviewed after deployment
- Exclusion owners and review dates recorded
- Customer administrator recovery rehearsed
- Ongoing audit cadence agreed
Conditional Access administration is most valuable when the business can explain why every policy exists, who it affects and how the tenant recovers from an error.
Primary technical references
Check current feature and licence requirements before changing a tenant. A service description is not evidence that a customer has purchased or activated an option.
Commercial next step
Review Conditional Access readiness
Share approximate users, Entra licensing, device mix and the authentication risks you're trying to address. No tenant credentials are needed for the initial conversation.
Request an administration assessment