What Conditional Access policy plans change for Maester and operations

My starting question was about Maester: if Conditional Access protection moves into policy plans, will our existing tests still see it?

That question quickly became broader. Plans introduce a parent configuration, shared targeting, individual rules and recorded owners. Those objects also have to make sense in sign-in investigations, audit trails and change processes.

The first result explains why this matters. Two plan rules appeared in What If and sign-in evidence, while the tested Maester collectors continued to return only the same 19 standalone policies. Entra was evaluating configuration that those checks had not collected.

The interesting change is the relationship between configuration, effective targeting and evidence. A plan needs to be understood as a parent and its rules throughout that chain. Here is what that means for operating Conditional Access, and why it led to a Maester contribution.

From one policy object to a parent and its rules

A standalone policy exposes conditions and controls on one object. A policy plan introduces a parent with shared conditions and child rules with their own conditions, state and nested controls.

Concern → Standalone policy → Policy plan and rules

• Targeting: Conditions on the policy → Shared conditions combined with rule conditions
• Enforcement state: Policy state → State on each rule
• Controls: Grant and session controls on the policy → Controls nested on each rule
• Accountability: Existing CA administration and governance → Additional owner metadata on the parent plan
• Configuration lookup: Policy ID → Plan ID and rule ID
• Sign-in evidence in this tenant: Policy entry → Rule entry requiring a parent lookup

The plan becomes a useful place to express common scope and responsibility. Its rules describe the individual requirements within that scope. Microsoft also exposes plan tags, a version and a template reference, giving inventory and change tooling more metadata to retain. Plan resource, rule resource.

That gives a collector three relevant configuration endpoints:

/beta/identity/conditionalAccess/policies
/beta/identity/conditionalAccess/plans
/beta/identity/conditionalAccess/plans/{planId}/rules

The parent contributes targeting. Each rule retains its own enforcement state. A check written for policy.grantControls also needs an adapter for rule.controls.grantControls. Owner metadata belongs to the plan.

That is a structural change for tooling built around one flat policy collection. A plan with several rules cannot be represented by one additional row without losing the controls and states of those rules.

Shared targeting changes the scope of a change

Shared conditions apply across the rules in a plan. Moving common targeting to the parent makes it easier to maintain, while making a parent-level edit relevant to several requirements at once.

A more interesting probe put user A and Windows in the shared conditions, then added user B and Android in the rule. Entra’s evaluation returned both users and both platforms in the effective condition set. All four user/platform combinations matched.

Scenario → Rule applied in What If

• User A on Windows: Yes
• User A on Android: Yes
• User B on Windows: Yes
• User B on Android: Yes

Those tested inclusion lists were unioned. Adding a platform to a rule could therefore broaden that collection beyond the platform recorded on the parent. This is worth checking whenever someone describes a plan as Windows-only.

This changes the review question. Looking only at a child rule can hide inherited users, applications or exclusions. Looking only at the parent can miss targeting contributed by a rule. The meaningful object for a security check is the rule with its effective conditions.

A general-purpose adapter needs field-specific merge behavior. Exclusions, filters, guest types and tenant sets carry different meanings. Combining two guest type/tenant pairs independently can invent combinations neither source intended.

The proposed Maester adapter preserves inherited targeting and exclusions, and rejects combinations it cannot safely flatten. A conflicting filter should produce an explicit assessment error instead of an invented effective configuration. What If remains useful for checking concrete sign-in scenarios. Scenario evaluation API.

The Maester impact starts with inventory completeness

A collector can correctly inspect the evidence it receives while leaving an additional configuration source unassessed. Conceptual illustration.

I compared Maester 2.3.0 and 3.0.0-rc65 against the same tenant baseline. Both collected the standalone policies but omitted the additional plan rules.

Inventory → Before the plan → Two report-only rules → Two enabled rules

• Standalone policies returned by the collector: 19 → 19 → 19
• Rules in the separate plan inventory: 0 → 2 → 2
• Plan rules returned by the collector: 0 → 0 → 0

The selected CA test result counts remained unchanged against each version’s own baseline. That was the reason to inspect the input behind the score: an unchanged result did not mean the new configuration had been assessed.

This establishes incomplete input for checks using that collector. It does not establish that every result was wrong: individual requirements may already be satisfied by standalone policies. It does mean those checks could not assess the additional plan rules from their configuration inventory.

This can affect both coverage checks and configuration hygiene. A requirement implemented only by a plan may be missed; a risky rule may also remain unexamined. The precise effect depends on the check and on any standalone policies that already satisfy it.

Maester therefore needs both inventories and an effective rule view. Searching plans only after a coverage check fails can help a specific requirement, but a complete collector also needs plan rules when inspecting exclusions, controls and other policy properties.

Sign in logs still report individual results

The runtime evidence was more familiar than the configuration model. Plan rules appeared in appliedConditionalAccessPolicies, using the rule ID and rule name. In the captured entries, there was no parent plan ID.

Rule state or applicability → Result observed in sign-in evidence

• Disabled rule: notEnabled
• Enabled rule with an unmet requirement or block: failure
• Rule excluded by shared targeting: notApplied
• Enabled MFA rule on a successful sign-in: success

Plans do not make every result a plan-wide verdict. The useful unit in these events remained the individual rule. Separate standalone policies also continued to apply: exclusion from the plan did not exempt the user from an existing MFA policy.

Inherited user and application conditions appeared as satisfied even when those fields were empty on the child rule. A rule-only configuration snapshot would therefore give an incomplete explanation of why Entra applied it.

A lookup of a live rule ID under the standalone /policies/{id} endpoint returned 404. The corresponding /plans/{planId}/rules/{ruleId} lookup succeeded. Keep a rule-to-plan mapping when enriching sign-in events; display names are an unreliable join key.

For a SIEM enrichment job, investigation script or report link, retain the rule ID, parent plan ID and both names when collecting configuration. Resolve a log entry against that combined inventory. A 404 from the standalone policy endpoint alone cannot establish that the logged object was deleted.

The result vocabulary is familiar, but the lookup behind it changes. Microsoft documents the result values on the applied policy resource. The rule IDs and missing parent context above were observed in this tenant’s sign-in records.

Audit logs expose a parent and rule relationship

Audit events used activities for creating, updating and deleting plans and rules. Rule audit details included PlanId, PlanDisplayName and Category, providing useful parent context that was absent from the sign-in rule entries.

A shared-condition change can affect several rules even when the change is recorded against their parent. A rule edit belongs to that parent’s history as well. For investigation and change review, collecting only the events whose names match an old standalone-policy workflow can leave relevant changes outside the view.

Evidence source → Context available in this tenant → Operational consequence

• Sign-in CA entry: Rule ID, rule name and result → Enrich it with the parent plan
• Rule audit event: Parent context including PlanId and PlanDisplayName → Group rule changes with plan changes
• Plan and rule inventory: Shared targeting, rule controls and state → Reconstruct what the rule means
• Current owner metadata: Recorded user or group IDs → Check accountability separately from enforcement

Change history also needs configuration snapshots. A current plan lookup describes the current scope; it cannot by itself prove what the inherited scope was at the time of an older sign-in.

One audit observation remains open. Matching events for a bulk 100-rule plan creation and two 100-rule plan deletions were absent from the retrieved audit set, while smaller operations had matching events. The search covered 1,671 events, pagination and a delay of more than 20 minutes.

That is a possible audit-completeness gap to reproduce, rather than a confirmed defect or documented size threshold. For operational tooling, it is a reason to reconcile change events with configuration inventory instead of assuming that one event query proves completeness.

Owners add accountability without granting edit rights

The owner badge, the plan’s operation and the administration key represent separate concerns. Conceptual illustration.

Microsoft defines plan owners as metadata, with no role or permission granted by the entry. The direct comparison supported that boundary: a user without an Entra role received 403 AccessDenied for the same plan-description PATCH before and after being recorded as an owner. Owner semantics.

An owner entry therefore cannot replace the administrator role or the authorization needed by a change workflow. The test covered plan-description updates; it does not establish the behavior of every editing surface.

Graph accepted user, security-group, Microsoft 365-group and distribution-list IDs in the owner collection. That is metadata acceptance, not evidence that each group type works as an access-package resource or CA targeting group.

An existing plan could be saved with owners: [] through both Graph and the portal. Ownership hygiene needs an explicit check; the tested edit form did not enforce a non-empty owner collection.

A working plan can have a broken ownership lifecycle

Deleting the recorded lab owner left its ID in the plan’s owner collection. What If continued to evaluate the active rules. The separate approver group, whose only member was that user, became empty.

The consequence is an operational dependency: enforcement can continue while accountability or approval reachability has degraded. A rule continuing to apply does not tell us whether anyone can still review its purpose or approve a related exception.

This gives us distinct hygiene questions: is an owner recorded, does that directory object still exist, is the account active, and can the responsible group still supply an approver? A populated string array answers only the first.

The proposed owner check, MT.1275, deliberately stays at that first layer. It flags existing plans with an empty owner collection as a low-severity finding. A deleted owner ID can still pass that presence check. Resolving identities and inspecting group membership belong in additional lifecycle checks with their own directory-read requirements.

Plans are optional. A tenant using standalone CA policies and no plans should receive Skipped / NotApplicable for a plan-owner check. A forbidden or failed API read is an error, not evidence of an empty inventory.

Access packages can govern exceptions behind a plan

An access package can provision membership in a group used by a plan exclusion. That gives a governance workflow a concrete connection to effective targeting: approved, time-bounded membership can control who receives an exception.

The exception’s scope needs particular attention. A shared exclusion can remove the user from every rule in the plan. Its business purpose, approvers and duration should match that scope, while other applicable CA policies remain relevant.

Membership provisioning and removal changed both rules’ applicability in What If. Those operations used administrative assignment requests, which bypass human approval. The result demonstrates the group-to-exception connection; it is not proof of a completed human approval flow. Access-package approval, assignment request types.

Owners do not automatically become access-package approvers. That relationship must be configured and maintained explicitly. Approval of an exception and approval to edit Conditional Access are also separate decisions.

Migration changes what an assessment must discover

Microsoft’s migration guidance creates plan rules while leaving the original policies unchanged. Generated rules start off, then progress through validation and report-only before enforcement and a separate cutover from the originals. Both representations can therefore coexist. Migration guidance.

The testing implication follows from the inventory result. While an active original policy remains, a collector may still assess its configuration. After that original is disabled, equivalent protection supplied by a plan needs to be discoverable and understood by the check.

A migration review should therefore compare targeting, exclusions, state and controls, then verify the intended cutover. Counting objects with similar display names cannot establish equivalence.

The assessment question is whether the effective requirement is covered by an enabled standalone policy or an enabled plan rule. Report-only evidence remains useful for validation, but does not supply the same enforcement claim.

Capacity needs separate policy and rule counts

Plans also change what it is useful to count. This tenant accepted 100 rules in one plan and rejected rule 101. At the peak, six plans contained 256 rules alongside 244 standalone policies.

Standalone policy 245 was rejected, while an additional plan and rule could still be created. Removing the capacity plans did not release another standalone-policy slot. That supports separate accounting for these inventories in this tenant, with a per-plan rule boundary.

The observed 244 standalone policies exceeded Microsoft’s published 240-policy limit. It is a tenant observation, not a replacement universal limit. The capacity objects were disabled; these counts measure saved configuration.

For Maester and governance dashboards, track standalone policies, plans and rules separately. A policy count alone now says less about the amount of configuration that needs assessment.

Read only assessment still needs reliable API access

Policy.Read.All worked for the standalone inventory, plans, rules and What If in the permission comparison. Policy.Read.ConditionalAccess alone returned 403 for the tested policy, plan and evaluation requests, despite being documented as least privilege for plans and evaluation. The rules request was not independently tested with the narrow scope after plan discovery failed.

Because the classic endpoint also returned 403, this does not establish that plans caused a scope regression. It is a reproducible discrepancy to investigate, scoped to the tested tenant, app and authentication mode.

The Maester collector needs read access, not policy-write permission. It also needs to distinguish an API failure from a successfully read empty inventory. Plan permissions, standalone policy permissions.

Bringing the effective model into Maester

The contribution is Maester PR #2733. It adds a cached plan/rule inventory and projects each rule into the shape existing CA checks consume. It retains effective conditions, rule state, grant and session controls, the actual rule ID and parent-plan metadata. Report links open the plan.

That control logic matters: MFA OR compliant device can be satisfied by a compliant device without MFA. MFA AND compliant device requires both. Discovering a rule is the first step; the check still has to interpret its requirement correctly.

The adapter buffers the inventory so failed reads do not silently return a partial set. It preserves report-only and disabled states and rejects unsafe merges. It does not redefine existing benchmark pass criteria or implement Entra’s complete sign-in evaluation engine.

The proposed MT.1275 check adds a small, separate ownership signal: an existing plan should record an owner. No plans means NotApplicable, while an unreadable plan inventory remains an assessment error. Resolving deleted owners and empty groups would require additional lifecycle checks and directory-read permissions.

The contribution has automated regression coverage for targeting, exclusions, states, controls, pagination, API errors and report links, alongside a live inventory check. It is under review and was not present in the two versions used for the original comparison.

The question to ask of the next security report

Plans change how Conditional Access configuration is organized and governed. The sign-in results in this research still describe individual rules, while explaining those results now requires the rule and its parent. Audit analysis and ownership hygiene need the same broader view.

For a Maester report, the first question is consequently simple: did the assessment collect and understand the objects that implement the requirement? A stable score is useful only after that inventory question has an answer.