Microsoft 365, Entra and Intune
Conditional Access policies small business tenants need, and nothing more
There is a policy in your tenant called TEST DO NOT ENABLE. It is enabled. It
has been enabled since somebody switched it on to check whether it worked, at
which point it did work, and the name stopped being something anyone read.
Conditional access policies small business tenants actually need come to about seven. Not the forty in a reference architecture written for an enterprise with a change board, and not the two that Security Defaults gives you. Seven, each with a job you can state in a sentence.
The conditional access policies small business tenants need
Require MFA for all users. The one that matters most. Every user, every cloud app, with your break-glass accounts excluded. If you only ever deploy one policy, this is it.
Block legacy authentication. Legacy protocols cannot present an MFA challenge, so without this the policy above has a hole in it. This is the policy most likely to break something, because something in your estate is probably still using basic auth on IMAP or SMTP, and finding out which is the entire value of report-only mode.
Require MFA for administrators, separately from the all-users policy, with no exclusions beyond break-glass and with session controls that do not permit "remember this device". Administrative sessions should be short and re-authenticated.
Require a compliant device for administrators. Once Intune is enrolling your machines, this is the policy that stops an administrator signing in from an unmanaged personal laptop. Deploy it after device compliance is actually working, not before.
Block sign-in risk, or require MFA on it. Needs Entra ID P2 for risk-based conditions. If you do not have P2, skip it rather than pretending: this is one of the places where the licence genuinely gates the control.
Restrict guest access. Guests should reach the specific things they were invited for and not the whole tenant. Pair it with the review cadence in the guest cleanup note.
Require MFA for device enrolment. Closes the gap where somebody enrols a device without a strong credential and thereby satisfies the compliant-device policy above.
That is the set. Everything beyond it is refinement, and refinement without the above is decoration.
Report-only first, without exception
Report-only mode evaluates a policy against real sign-ins and records what would have happened, changing nothing. Microsoft's report-only mode documentation covers reading the results in sign-in logs.
The temptation to skip it is strongest on the policy that most needs it. Block legacy authentication looks obviously correct and it is the one that will break a scanner in the office that emails scans through SMTP, or a monitoring integration nobody documented, or a mail client on a director's phone.
A week in report-only tells you which. That week costs you a week. Not doing it costs you an outage on something business-critical that you then have to diagnose under pressure, having just changed identity policy, which is the worst possible time to be reading sign-in logs for the first time.
The discipline that makes this work is a naming convention with the state in the
name. CA01 - Require MFA - All users - REPORT ONLY becomes
CA01 - Require MFA - All users when you promote it. Then a policy whose name
disagrees with its state is visibly wrong, and TEST DO NOT ENABLE cannot
happen.
The exclusion that keeps you employed
Every policy above excludes the break-glass accounts. This is not optional and it is not a compromise.
A one-person tenant has no colleague with Global Administrator to undo a policy that locked everybody out. The recovery path is a Microsoft support case, which takes hours you do not have while nobody can log in. Two cloud-only accounts, excluded from every Conditional Access policy, monitored for any use at all, are the thing that turns that scenario from an incident into an inconvenience. The break-glass note covers how to set them up and, more importantly, how to test them.
Exclude a group rather than named accounts, so adding a third emergency account later does not mean editing seven policies.
The exclusions that are load-bearing and look wrong
A warning, because this is a genuine trap and I have watched it bite.
Some exclusions in a working tenant are required configuration rather than oversights. A service principal excluded so an automation flow can run. An application excluded because its own authentication does not support the control you are enforcing. A specific sign-in scenario excluded because the platform requires it.
Before removing any exclusion you did not create, find out what it is for. An exclusion that looks like laziness is sometimes the only reason a remote access product or a device sign-in flow works at all, and removing it produces an outage whose cause is not obvious, because nothing appears to have broken except one specific journey.
Write the reason into the policy description when you find out. That is the cheapest possible fix for the next person, who will be you.
Where this sits
Getting this set right, in report-only, with the evidence to show it, is most of what a customer security questionnaire is asking about identity, and it is Annex A 5.15 and 8.2 territory if you are heading for certification.
If you would rather it were done with you than by you, that is the security and compliance work. The rest of the Microsoft 365 notes cover the surrounding pieces.
Questions
Is Security Defaults enough for a small company?
It is much better than nothing and it is free. It enforces MFA and blocks legacy authentication with no configuration. What you give up is granularity: you cannot exclude a break-glass account, you cannot run anything in report-only, and you cannot treat administrators differently. Start there if you have nothing, and move to Conditional Access when you need an exception, because the first exception is what forces the move.
Do I need Entra ID P1 or P2?
Conditional Access needs P1, which comes with Business Premium and E3. The risk-based policies need P2. If you are on P1, deploy the six that do not need risk conditions and leave the seventh.
How long should I leave a policy in report-only?
Long enough to cover a full business cycle for whatever it touches. A week for most things, a month if it affects something that only runs at month end. Payroll and finance systems are the usual reason to wait longer.
What if report-only shows failures I cannot explain?
Do not promote the policy. An unexplained would-have-blocked result is the policy telling you something in your estate does something you do not know about, and finding out is the whole point. Promoting anyway converts a question into an outage.
Should the break-glass accounts have MFA?
They should have a strong credential, stored securely, and be excluded from policy enforcement so a broken policy cannot lock them out. The protection comes from the credential and from alerting on any use, not from the policy engine that might be the thing that has failed.