On Business Premium you already own this outright, and the odds are nobody has built any of it.
This needs P1, and Business Premium customers can use it as well. Most American small and mid-sized businesses on that plan have never configured a single policy. It is the one control deciding who reaches your data, it is the first thing any insurance questionnaire asks about, and the risk in it lives entirely in the exclusions rather than in the policies themselves.
- P1 or Business PremiumYou may already have it
- After first factorNot a frontline defense
- ExclusionsWhere the real gap is
- Report-only firstNever deploy blind
Eight things to understand before writing a single policy.
The license you probably already hold
Using this requires P1 licensing, and separately, Business Premium customers can use the features too. A large share of American small and mid-sized businesses run Business Premium, usually bought precisely for the security in it, and have never once opened this part of it. If that describes you, the gap in front of you is configuration rather than budget.
It runs after first-factor authentication, not before
This is stated outright: policies are enforced only after the first authentication has already completed, and none of it is intended as a frontline defense against something like a denial of service attack, though it can consume signals from one. It matters because people describe this as a gate at the door. It is a gate immediately behind the door, and that changes considerably what it can and cannot protect you from.
Signals, which is what makes it conditional
A policy can weigh the person, the group or the agent, the address they are coming from including entire countries, the platform and state of their device with filters precise enough to target something like a dedicated administrative workstation, which application they are reaching for, and the risk calculated either live or over time. Agent identities are in preview and extend all of this to AI workloads, which is worth knowing about before somebody makes it a requirement.
Decisions, and the honest ranking of them
Blocking is the most restrictive answer available. Granting can demand multifactor, a named authentication strength, a device marked compliant, a hybrid joined device, an approved client application, an app protection policy, a password change, or somebody accepting your terms of use. Most companies use two of those and would benefit from three or four, with authentication strength and device compliance being the two most commonly missing.
Exclusions, which is where policy sets actually fail
The policy list looks thoroughly robust while all the risk sits in what has been left outside it. Service accounts excluded during an implementation three years ago, an emergency account nobody has ever tested, an exception created for one executive going abroad and never removed afterward, a group whose membership has quietly tripled. We read the policies as a set rather than one at a time, because a set is how an attacker encounters them.
The Coverage tab, which almost nobody opens
There is a coverage view showing which applications have had policy applied over the past week and which have not. That is the quickest route to finding an application nobody ever protected, and in most tenants we open, nobody has ever looked at it. It costs nothing, takes about a minute, and regularly turns up something more useful than a full policy review would have produced.
Report-only mode and the modeling tool, so nobody gets locked out
Any policy can run in report-only, showing exactly what would have happened without actually doing it, and there is a tool for modeling one specific person in one specific situation before committing to anything. Skipping both is how a company finds out on a Sunday afternoon that its entire finance team is locked out. Everything we deploy runs in report-only first, and we read the results properly rather than glancing at them and assuming they are fine.
What happens if the license lapses
A useful detail hardly anybody knows. When the licensing behind this expires, the policies are neither disabled nor deleted, so nothing about your posture changes overnight. You can read what remains and remove it, though you cannot edit it. That is a gentle failure rather than a cliff edge, and it is worth understanding before a renewal decision rather than three months afterward.
A policy list that looks entirely solid, carrying three exclusions, protects nothing at all.
These two findings come up more than any others, and both are completely invisible to anybody reading the policy list rather than reading what has been placed outside it.
- Exclusions nobody can account for. Every deployment collects them over time. A service account carved out during an implementation because something stopped working. An exception for somebody going abroad. An application dropped onto a bypass list during a migration. Every one was reasonable at the time and every one was temporary. Not one was ever removed. The test is simple and thoroughly uncomfortable: for every exclusion in every policy, can somebody say why it is there and when it ought to end.
- Emergency accounts nobody ever tested. The guidance is to exclude them from Conditional Access so that a badly configured policy cannot lock every administrator out of the tenant at once. That guidance is correct, and following it creates a permanently excluded account holding very high privilege. If nothing watches it, and if nobody has ever confirmed it actually works, you have taken on the risk and gained none of the benefit. Test it, alert whenever it is used, and store its credentials properly rather than in a drawer.
- A third pattern worth naming: policies that grant where somebody intended them to block. A policy requiring multifactor for one group protects the members of that group and nobody else, and group membership drifts continuously. Targeting everybody, with a short list of deliberate exclusions, is nearly always more robust than targeting a group somebody has to remember to maintain.
- The practical place to start is not writing further policies. It is listing every exclusion across every policy you already have, putting a name and a reason beside each one, and deleting the ones nobody can defend out loud. That exercise closes more genuine risk in most tenants than any additional rule would, and it produces exactly the answer an underwriter is looking for when they ask whether multifactor is enforced for everybody.
Four things that keep a policy set working long after we have gone.
We check what your license already covers first
Business Premium customers can use these features, and a large share of American small businesses hold that plan without realizing what comes with it. Where the capability is already yours, the work is configuration and there is nothing whatsoever to buy. That gets established before any conversation about licensing, because recommending an upgrade nobody needs is the quickest way to lose a client permanently.
We audit the exclusions, not just the policies
A policy list is easy to read through and tells you remarkably little. What matters is who and what has been placed outside each policy, and whether anybody can justify it. What we produce is a named list of every exclusion, each with a reason and an owner attached, and whatever nobody can defend gets deleted. That finds more genuine risk than writing further rules, and it is the part almost every review skips.
Report-only comes first every single time, and somebody reads what comes back
Every policy runs in report-only before anybody enforces it, and what it would have blocked gets worked through with the people it would have affected. Failures here are extremely visible and tend to land on senior people, so an unannounced enforcement that blocks the finance team on the last day of the month costs considerably more goodwill than the policy was ever worth.
It stays simple enough that your own team can maintain it
A few policies covering everybody, with exclusions chosen on purpose and written down, beat a large collection aimed at groups somebody must remember to update. The standard we hold ourselves to is that your own administrator can talk through the whole thing in ten minutes. If they cannot, it will drift, and it drifts in exactly one direction, which is toward more exceptions.
Six US situations where conditional access is the deciding control.
A company on Business Premium that has never once configured any of it
The commonest situation we walk into and by some distance the easiest to fix. Somebody bought the plan for its security features, nobody ever configured the device management or the access policies, and the company is currently protected by whatever the defaults happen to do on their own. There is no license to buy and no purchasing conversation to have, which makes it unusually easy to justify to anybody holding a budget.
A financial services firm under state or federal expectations
Access control is examined in audits and client due diligence, and conditional access is where most of the answer lives for a Microsoft estate. Frameworks that apply to US financial firms, from the FTC Safeguards Rule to New York DFS cybersecurity requirements, put multifactor authentication and control over privileged and remote access at the center, and all of that maps onto policy design.
An organization with staff traveling or working remotely
Conditions based on location, on device compliance and on app protection only start to mean anything once people are working outside an office network, which for most American businesses is now simply how things are. It is also where exceptions pile up fastest, because an exception for somebody traveling gets granted in five minutes under pressure and removed by absolutely nobody. A properly designed set treats remote working as a condition rather than as a permanent exception.
A company managing devices with Intune
Insisting a device be marked compliant is what converts device management from a reporting exercise into an actual access decision, and it is the connection most companies have never made. Where compliance is visible but nothing enforces it, you are describing risk rather than preventing any of it, and joining the two together is usually a small configuration change rather than a project.
An organization holding regulated or personal data
Under HIPAA for covered entities and their business associates, and under CCPA and CPRA alongside the growing pile of state privacy laws, controlling who reaches protected and personal data is a direct obligation rather than a recommendation. This is the mechanism by which that control gets applied in a Microsoft environment, and it generates evidence as it goes, which is precisely what an assessor or a large client will ask you to produce.
A business that failed a security questionnaire or insurance renewal
Questions about whether multifactor is enforced, what is required of a device, and how administrative access is handled appear on every enterprise vendor questionnaire and every insurance application, and they are answered accurately or they are not answered at all. A properly designed policy set answers most of them directly. The awkward version is writing yes against multifactor enforcement while three service accounts and two executives sit outside every policy you own.
What we typically find when we open up conditional access in an American tenant.
| Feature | Designed and maintained | Policies with drifted exclusions | Security defaults or nothing |
|---|---|---|---|
MFA enforced on all users | Mostly | Partly | |
Administrators covered by a stronger policy | Same as users | ||
Legacy authentication blocked | Sometimes | ||
Every exclusion has a name and a reason | Not applicable | ||
Break-glass accounts tested and monitored | Untested | None exist | |
Device compliance gates access | Reported only | ||
Coverage checked for unprotected applications | |||
Policies tested in report-only first | Some | Not applicable | |
Policy set explainable to an auditor | With difficulty | Nothing to explain | |
Frequency in the US mid-market | Uncommon | Common | Common in SMBs |
Security defaults, P1 and P2, compared on the points that actually decide things.
Capability
Security defaults
- What is needed
- Available to all customers
Capability
Conditional Access policies
- What is needed
- Entra ID P1
Capability
Conditional Access with Business Premium
- What is needed
- Included, Microsoft states these customers can use it
Capability
Require multifactor authentication
- What is needed
- P1
Capability
Require compliant or hybrid joined device
- What is needed
- P1, plus Intune for compliance
Capability
Require approved client app or app protection policy
- What is needed
- P1, plus appropriate Intune licensing
Capability
Location and country based conditions
- What is needed
- P1
Capability
Report-only mode and What If
- What is needed
- P1
Capability
Sign-in risk and user risk policies
- What is needed
- P2, via Microsoft Entra ID Protection
Capability
Conditional Access Optimization Agent
- What is needed
- At least P1, plus security compute units
Capability
When licenses expire
- What is needed
- Policies carry on running and can be read or removed, though never edited
Five stages, and nothing is enforced until stage four.
- 1
Establish what exists today and what your licensing actually permits
The policies as they stand along with every exclusion on them, whether security defaults are still in force, and whether you hold P1, Business Premium or P2. That final answer decides whether risk-based policies are available to you at all, and a plan built around them for a P1 tenant is a plan nobody can implement.
- 2
Audit the exclusions and the coverage gap
Every exclusion written out by name, then either justified in writing or removed, and the coverage view read to find applications no policy protects at all. This stage regularly produces the most valuable findings in the entire engagement, and it requires no changes to anything and no licenses whatsoever.
- 3
Design a small, explainable policy set
Baseline policies aimed at everybody with the exclusions documented, a stronger set covering administrative roles, the legacy protocols closed, and requirements around device or app protection wherever your licensing and device management can support them. Deliberately few policies in total, because a set nobody can explain is a set nobody will maintain.
- 4
Run report-only, actually read what comes back, then enforce in waves
Every policy runs in report-only, what it would have blocked gets worked through with the people it would have affected, and enforcement proceeds in stages beginning with the administrators. Nothing is switched on until a person has looked at the impact, and the emergency access gets tested before anything is enforced rather than during the incident afterward.
- 5
Write it down, prove the emergency accounts work, and fix a date to revisit
A brief written note explaining what each policy does and why each exclusion is there, an alert whenever an emergency account is used, and one fixed date in the year when every exclusion has to be justified again. Exclusions accumulate continuously and without pause, so that review is the only control preventing the whole set decaying back to where it began.
What US organizations ask about conditional access.
Fifteen questions, and most can be answered from the portal this afternoon.
What exists today
- Are you using security defaults, conditional access, or neither?They are alternatives. Many tenants have neither properly.
- Do you hold Entra ID P1, or Business Premium?Either gives you conditional access. Check before buying.
- How many policies are enabled versus report-only?A tenant where every policy sits in report-only is enforcing precisely nothing.
- Have you opened the Coverage tab?It shows which applications are covered by policy and which are not. Almost nobody has ever opened it.
- Is legacy authentication blocked?It cannot enforce multifactor at all, and it is the single most abused route in.
The exclusions
- Write out every exclusion in every policy. Can each one be defended?The single most valuable exercise on this page.
- Which service accounts are excluded, and why?Usually excluded during an implementation and never revisited.
- Do emergency accounts exist, and has anybody ever tested one?Excluded by design, so they must be monitored.
- If an emergency account signed in tonight, would anything alert?An untested, unmonitored emergency account is a liability.
- Are any exclusions temporary arrangements that were never removed?Travel exceptions are the classic case.
Would it hold
- Are the policies aimed at everybody, or at groups somebody has to keep updated?Group membership drifts. All-users plus exclusions is sturdier.
- Is device compliance required for anything, or only reported?Reported non-compliance changes nothing on its own.
- Do administrative roles sit under a stronger policy than ordinary staff?A common gap, and the one that matters most.
- Was every policy tested in report-only before enforcement?And did somebody actually read the results.
- Could somebody explain the whole set to an auditor inside ten minutes?If not, it is almost certainly too complicated to stay reliable.
The pages around this one.
Microsoft Entra
The wider identity platform: what it covers, how it fits a US Microsoft estate, and the practice conditional access sits inside.
Cybersecurity audit and compliance
A full security review where conditional access gaps are one finding among many, alongside identity, mail, sharing and audit retention.
Microsoft security
The whole Microsoft security stack, and an honest view of what your existing licensing already covers before you buy anything more.
Open the Coverage tab and list your exclusions.
Both take minutes, cost nothing, and between them tell you most of what a review would. If your license turns out to include conditional access already, which for Business Premium it does, then whatever you find is a configuration problem rather than a purchase.
Related Services
Explore more solutions that work great with this service
Conditional Access Authentication Strengths
The right credential strength for each access decision
Learn moreMicrosoft Entra ID P1 and P2 Licensing Review
Independent Entra ID P1 against P2 advice for US organizations:
Learn moreMicrosoft Entra Token Protection
Tokens bound to the device that requested them
Learn morePhishing-Resistant MFA
Phishing-resistant multifactor authentication for US organizations:
Learn moreEmergency Access Account Design
Break-glass emergency access account programs for US organizations:
Learn moreMicrosoft Entra
Identity and access management solutions
Learn more