One Policy, One Job: The Habit That Makes a Tenant Predictable
You get the ticket. A user's blocked and they need in now. You open the policy that caught them, and it's doing five things at once. MFA, a device rule, a location condition, a couple of grant controls stacked on top of each other. The sign-in log tells you the policy applied. It doesn't tell you which part of it did the blocking. So you're guessing, on the clock, on a live tenant, with someone waiting on you.
I've watched a lot of engineers land in that exact spot. It's rarely a hard problem. It's a hygiene problem, and it's the first rule I teach.
One policy, one job. If you need MFA and you need compliant devices, that's two policies, not one policy carrying both. A policy that does a single thing reads as one clear statement: who it hits, where, and what it requires. You can look at it and know what it will do before it does it.
That last part is the whole game.
What “technology” actually means
We throw the word “technology” around like it means the gear. It doesn't. Break it down. Tekhne is the Greek for craft, or skill. The suffix -logy means the study of. Put them together and technology is the craft of taking what you know and making it work in the real world. Not the knowing. The applying.
Anyone can pull up a page on what Conditional Access is. That's knowledge. Building a policy that behaves the way you meant it to, on every sign-in, with no surprise, that's the craft. And the proof you've crossed from one to the other is predictability. When you can predict what a policy will do, you've applied the knowledge right. When you can't, you're holding theory against a live tenant.
Technology: the craft of putting what you know to work.
Overloaded policies hide their own behavior
An overloaded policy can't be predicted, and that's the problem. Stack four conditions and two controls together and you've built something nobody can read at a glance. It blocks someone and you can't say why without pulling the whole thing apart. You change one condition and you quietly change how every other piece behaves. Every edit becomes a guess.
Single-purpose policies take the guessing out. A few things get easier right away:
- The sign-in log becomes an answer. The Conditional Access tab lists the policies that applied to a given sign-in. When each policy does one job, that list tells you exactly what happened.
- You change one thing and one thing moves. No side effects hiding in the other conditions.
- You in six months, or the next engineer who inherits this, can read the name and know the scope. If the name says what it does and the policy does only that, nobody inherits a lie.
Is there a cost? More policies to manage. That's the trade, and it's worth it. The mess you're trading is the 2 am one, the change you can't undo because you can't tell what it touched.
One policy per job stays predictable. Stack them and every edit is a guess.
What good looks like, and one move today
What good looks like is pretty simple. You build a policy, you know what it'll do, you turn it on, and nothing surprises you. There’s no luck involved. That's the craft applied. Predictable inputs, predictable results, and a tenant you can think through instead of one you brace against where users are inexplicably impacted (halting production). This is the very first habit (hygiene) I drill with every team on coaching sessions.
Do one thing today:
- Open your policies and find the one carrying the most conditions and controls at once. Just that one.
- Split it into single-purpose policies, name each for the job it does, and run it in report-only before you enforce.
The next time something breaks, the log will hand you the answer instead of more guesswork.
That gap, between knowing what these controls are and applying them so they behave, is exactly where we coach. Not button paths. The judgment to build conditional access policies that do what you expect, every time.
Glossary
Conditional Access. the if-then rules at the front door of your tenant. For each sign-in they decide: let them in, block them, or let them in with conditions.
Conditional Access policy. one rule in that system. It sets who it applies to, the conditions that trigger it, and what it requires.
Single-purpose policy. a policy that does one job, so you can read it in a line and predict what it will do.
Condition. the “if” part of a policy: who is signing in, from where, on what device, to what app.
Grant control. what a policy requires before it lets a sign-in through, such as require MFA or require a compliant device.
MFA (multi-factor authentication). proving who you are with more than a password, like an app prompt or a one-time code.
Report-only mode. a setting that lets a new policy run and record what it would have done, without enforcing it, so you can check the result before you turn it on.
Sign-in log. Entra's record of each sign-in. Its Conditional Access tab lists the policies that applied to that sign-in.
Source: Microsoft Learn, “Conditional Access and Microsoft Entra activity logs” (learn.microsoft.com/en-us/entra/identity/monitoring-health/how-to-view-applied-conditional-access-policies).
