Conditional Access policies are not easy to write for a normal day, but we’re not covering that today. Policy plans, which Microsoft announced in public preview on November 4, give you a better place to design for the other kind of day, the one where something pushes back…we’re seeing more of those days than ever before.

Why choose non-Newtonian fluids as my metaphor? Because access control should behave the same way: change its behavior based on how hard and how fast it is pushed.

Stay with me!

Water has one viscosity no matter what you do to it.

Oobleck, the cornstarch and water mixture, does not. Press slowly and your hand sinks in. Hit it fast and it behaves like a solid.

Ketchup does the reverse and flows more easily when shaken.

Toothpaste holds its shape until you squeeze past a threshold.

Each is a different answer to the same question: what should this thing do under stress?

Three behaviors worth designing on purpose

1. Hold shape until a threshold (toothpaste). Who is in scope, what is covered, who is excluded for break-glass. This should not move under pressure.
2. Flow when stress is low (ketchup). A user on a compliant device with a passkey should never feel the policy. People route around controls that tax them for no reason.
3. Harden when stress is high and fast (Oobleck). A risky sign-in, a risky agent, an unfamiliar device. The control tightens without a ticket.

What plans change

A policy is one standalone if-then rule.

A plan is a container that holds shared targeting plus several rules. They run side by side, and access is granted only when every applicable policy and rule is satisfied.

A plan organizes access. Conditional Access still decides the same way, so my recommendation is to treat the new plan as a design tool.

In practice, you set shared conditions once, and each rule inherits them and adds its own controls. Rules can add exclusions, but they cannot remove or override the ones set at plan level. Each rule shows up as its own entry in the sign-in logs.

In the fluid model, shared conditions are the toothpaste tube. They set the shape. Rules are the responses to stress.

Example 1: an administrator plan

• Shared conditions: your admin roles in scope. Two break-glass accounts and your required service accounts excluded, once.
• Rule A, phishing-resistant MFA: ketchup. Admins with a hardware key or passkey barely notice it.
• Rule B, compliant device required: toothpaste. It holds until the device falls out of compliance.
• Rule C, a sign-in risk condition that blocks or steps up: Oobleck. It does nothing on a calm day and hardens when the risk signal spikes.

One caveat from the docs: “All users” is not available at plan level, so you scope a plan to a defined population on purpose.

Example 2: an agent plan

Agents have no one to challenge. Per Microsoft, an agent that acts with its own identity has no remediation path, so block is the only grant available.

• Shared condition: agent risk, set once.
• Rule A: block high-risk agent identities.
• Rule B: block agent user accounts at medium and high risk.
• Rule C (the yield point): use custom security attributes to separate agents by approval status. Microsoft’s Zero Trust assessment gives AgentApprovalStatus with values like New and In_Review as an example. A newly registered, unvetted agent should not get the same access as an approved one.

Blocking only works if something consumes the signal. ID Protection can mark an agent as high risk, but without a policy that blocks it, the logs say compromised while the resource still says yes.

Example 3: migrating without loosening anything

Take three standalone admin policies and migrate them into one plan. The originals keep enforcing while the new rules start Off. Set the rules to report-only and compare against the originals in the sign-in logs. Then turn the rules On and turn the originals Off.

The overlap period matters. During evaluation, old policies and plan rules run independently, and every applicable one must be satisfied. Nothing gets looser mid-migration, but users may see the same control twice until you finish.

Where the model breaks

Oobleck hardens only under fast impact. Press slowly and it gives way. That is the low-and-slow attacker: a stolen token used quietly, a session that never trips a risk score.

A risk rule fires at sign-in, so it does nothing for a session that already exists. Two controls answer sustained pressure. Continuous access evaluation re-checks conditions during a session. Token protection ties a token to its intended device, so a stolen one is far less useful. A plan with strong risk rules and neither of these is Oobleck with a hole in it.

The preview has a limit that shows the same gap. Microsoft warns that for plans using the Location condition, users get one-hour access tokens with no instant IP enforcement check, as Microsoft 365 for IT Pros reports. A change in a user’s location may not be enforced for up to an hour. Test this before you lean on location rules inside a plan.

The second failure is quieter. A careless shared exclusion weakens every rule that inherits it. Your yield point is now a single setting, so defend it like one.

What to do this week

• Pick one objective, such as admin access, and migrate only that group.
• List the shared exclusions and name an owner for each.
• For every rule, write down what it does at low, fast and sustained stress.
• Pair risk-based rules with CAE and token protection.
• Run everything in report-only first. This is a preview, and preview behavior is not production behavior. LazyAdmin reports that plans are missing from standard Conditional Access backups, so check how you export yours.

A plan is a cleaner place to decide how your tenant behaves under pressure. Which of your controls would hold if the push came slowly?

P.S. Still editing the same exclusion in every policy? Time to ketchup!!