Nine policies, why each one exists, and the order to turn them on.
Nine policies, why each one exists, and the order to turn them on.
Most firms we assess have Conditional Access enabled and believe they are covered. When we open the tenant, we usually find three policies: an MFA policy with a long exclusion list, something that was turned on during a compliance push in 2022 and never revisited, and a legacy authentication block that was set to report-only and forgotten.
That is not a baseline. It is sediment.
Below is the set of policies we deploy in the first two weeks of an engagement. It is not exhaustive and it is not the ceiling. It is the floor, the configuration below which we will not operate a client environment.
Create two cloud-only global administrator accounts with long random passwords stored offline. Exclude them from every Conditional Access policy you are about to create. Alert on their sign-in.
This is the step people skip, and it is the step that produces the 2am incident where a misconfigured policy locks every administrator out of the tenant, including the administrator who would fix the policy. Microsoft's own guidance calls for this. Do it before you write policy one.
Legacy protocols (POP, IMAP, SMTP AUTH, older Exchange ActiveSync clients, Office 2010) cannot present an MFA challenge. An attacker with a valid password and a legacy endpoint bypasses every MFA policy you own. This is still, in 2026, the single most common initial access path we see in incident writeups.
Turn it on in report-only first and read the sign-in logs for two weeks. You will find a multifunction printer that scans to email and one finance application nobody remembers deploying. Fix those, then enforce.
Not "for admins." Not "for risky sign-ins." All users, all cloud apps.
Where you can, require phishing-resistant strength rather than any-MFA. Authentication strengths in Entra let you demand FIDO2 security keys, Windows Hello for Business, or certificate-based authentication. Push-notification MFA is defeated by fatigue attacks and by adversary-in-the-middle kits that proxy the entire session. Number matching helps. It is not a substitute.
For a firm where a single compromised inbox can move a position, phishing-resistant is not gold-plating.
Global Administrator, Privileged Role Administrator, Exchange Administrator, and the rest of the tier-zero roles get no fallback. No SMS, no voice call, no TOTP. Hardware key or Windows Hello, full stop.
Pair this with Privileged Identity Management so those roles are eligible rather than permanently assigned, and activation requires justification and approval.
This is the policy that turns a password from a key into a component. An attacker who phishes a credential and defeats MFA still needs a device your Intune tenant has marked compliant.
It is also the policy that generates the most user friction if you sequence it wrong, so it should not be your first move. Get devices enrolled and compliance policies tuned first, run this in report-only until your compliance percentage is above 95, then enforce.
Executives will read email on personal phones. You can accept that and control it, or forbid it and watch them do it anyway.
App protection policies (Intune MAM) let you enforce encryption, a PIN, and copy-paste restrictions inside the Outlook and Teams apps without enrolling and managing the personal device. Corporate data lives in a controlled container. Selective wipe removes it without touching the user's photos.
Combine with a Conditional Access grant that requires an approved client app. The native iOS Mail client cannot honor your policy, so it does not get to connect.
Requires Entra ID P2. If you have the license, use it.
Entra's risk detections (impossible travel, anonymized IP, leaked credentials, unfamiliar sign-in properties, token anomalies) feed two policies: high sign-in risk forces MFA, high user risk forces a secure password change. This is the closest thing to automated response you get without a full SOC.
If you are on P1 and the licensing gap is a budget conversation, have the budget conversation. For a firm holding market-sensitive research, leaked-credential detection alone justifies it.
If someone must reach Outlook Web from a device you do not manage, they should not get a persistent session and they should not be able to download files.
Conditional Access app enforced restrictions, paired with a sign-in frequency of one hour and no persistent browser session, turns a compromised unmanaged browser into a narrow, short-lived window rather than an open door.
Named locations are a blunt instrument and a determined attacker routes around them with a VPN. That is not the point. The point is that blocking countries where you have no staff, no clients, and no travel raises the cost and volume of noise for the opportunistic attacker, and produces a much cleaner sign-in log for the sophisticated one.
Keep the allowlist tight. Review it against actual travel, not against hypothetical travel.
Otherwise a stolen password registers an attacker's device, that device gets marked compliant by your own tooling, and policy 4 becomes a formality.
This is a small policy that quietly holds up several larger ones.
Order matters more than the list.
Weeks 1 to 2. Break-glass accounts. Every policy above deployed in report-only. Nothing enforced. Read the logs.
Weeks 3 to 4. Enforce legacy authentication block and MFA for all users. Enforce phishing-resistant MFA for privileged roles. These three are high value and low friction.
Weeks 5 to 8. Enroll devices. Tune compliance policies. Watch the compliance percentage climb. Do not enforce device compliance until it is high, because the day you enforce it, everyone below the line stops working.
Week 9. Enforce device compliance and mobile app protection.
Ongoing. Risk policies, session controls, and named locations, tuned against real signal rather than defaults.
We do not use Security Defaults. They are a reasonable floor for a company with no IT function. They are not configurable, and any firm serious enough to be reading this has outgrown them.
We do not build a permanent exclusion group called something like "MFA Exempt." Every exclusion we grant has a name, an owner, an expiry date, and a review. Exclusions that outlive their reason are how baselines rot.
We do not enforce a policy we have not first run in report-only. Ever.
None of this is proprietary. Every policy above appears somewhere in Microsoft's documentation, and a competent engineer could assemble the same list.
The work is not the list. The work is knowing that policy 4 will lock out the trader whose laptop failed a compliance check for a BitLocker recovery-key reason at 6:40am, that the exclusion someone grants to fix it will still be there in eighteen months, and building the process that catches it.
Need to harden your Entra ID posture?
KYA Consulting designs and operates Microsoft-stack infrastructure for firms where downtime is not an option. If you want a read on your current Conditional Access posture, get in touch.
Get in Touch