Publication fact ledger — September Microsoft security roundup

← Back to the article

Revalidated: September 12, 2026. The original ledger was checked on September 11 at approximately 23:15–23:20 UTC; the source refinements below reflect a subsequent review of current Microsoft documentation. This ledger contains public-source facts and proposed evidence requirements. It does not record new cloud tests.

September 12 source refinements

• Microsoft’s sensitive-action guidance explicitly limits Security Administrator, Security Operator, and Entra SOC Identity Responder to nonadministrative accounts. This documents the target boundary; the experiment still covered only an ordinary account and one Global Reader account.
• The current Sentinel generator guide names Automation: Automation Playbooks (Read and Write) in Defender unified RBAC, plus Sentinel Contributor on relevant workspaces or resource groups for rule authoring. It replaces the older introduction as the article’s implementation link. The older introduction’s Copilot setup requirements are superseded. Normal Sentinel billing and separately billed integrations remain distinct from the included generator and its zero-SCU operation.
• The risk-remediation guide distinguishes secure password change (known password plus MFA) from SSPR account recovery. The article now makes that distinction beside the SSPR crosslink.
• The current Defender cloud overview requires a paid Defender for Cloud plan for consumption in Defender, and current limitations exclude free-tier-only subscription resources. This is current portal eligibility, not a paid requirement for Foundational CSPM or proof of October’s eventual portal scope. Cloud scopes and unified RBAC remain in preview; Azure assignments do not automatically become Defender assignments.
• The memberOf preview already has a removal limitation before retirement. A group-based licensing cutover should follow Microsoft’s destination membership, license confirmation, source removal sequence. Nested groups do not provide equivalent license assignment. Access-package policy continuity remains a separate migration concern.

All five announced dates and affected populations remain supported. The report builders in the evidence package are restricted to the original historical inputs; fresh inventories should use the reusable GET-only collector and its own completeness fields.

Publication boundary

Use three distinct labels throughout the article: Microsoft-documented, observed in this lab, and not tested. A screenshot of an available control proves visibility only. Configuration evidence proves scope/state. An operator action plus outcome and audit evidence is needed for an executed-test claim. A tenant SKU proves neither per-user licensing nor endpoint/service eligibility.

The source-supported calendar is:

• August 6: Sentinel generator access expansion; updated August 7.
• September: Security Administrator response expansion; rollout scheduled complete by month end.
• October 1: legacy Entra ID Protection risk policies retire.
• October 27: Foundational CSPM default changes for NEW Azure subscriptions.
• November 3: memberOf retirement; access-package auto-assignment quarantine starts.

1. Security Administrator expansion and responder-role comparison

The source descriptions distinguish Entra targets, AD targets and SaaS accounts. A success on one is not evidence for all. Retain the exact role template/definition ID, operator identity class, active assignments, initiating portal/API and target class in the private lab record.

Licensing interpretation: No SCUs are required by these Entra directory actions. Do not state that every Defender investigation surface is universally unlicensed; workload access and unified RBAC are separate. PIM eligibility/activation, if used, is a further entitlement and session-state concern.

Proposed acceptance criteria:

1. Export the four relevant action memberships for Security Administrator, Security Operator and Entra SOC Identity Responder. Capture retrieval time and source IDs.
2. Inventory direct and group-based active assignments separately from eligibility where accessible. An incomplete PIM/group expansion must be marked incomplete, not zero.
3. Use an operator that has only the role being tested, with fresh authentication after role changes; a Global Administrator action cannot validate a narrower role.
4. For each exercised action, pair requested operation with independent target-state evidence and its directory audit event. Do not use a portal toast as sole evidence.
5. Keep password reset separate from require-password-change-at-next-sign-in; report the operation actually invoked.
6. If privileged targets are tested, use disposable targets and record exact role class. One denied target does not prove the entire privileged-account matrix.
7. Verify target restoration and removal of temporary operator assignments, preserving private evidence.

Screenshot targets: role definition/action list, scoped assignment evidence, one action result and corresponding audit record. Captions must identify definition-only evidence versus execution.

2. Sentinel AI playbook generator without Security Copilot capacity

Contradictions affecting conclusions: The how-to describes code validation during generation but says automatic validation is not provided in limitations. Treat generated code as needing review/test. The application card broadly discusses incident-driven workflows, while the operational guide specifies alert-only inputs; use the actual alert contract. Current generator entitlement does not mean an old tenant UI will necessarily be ready immediately.

Proposed acceptance criteria:

1. Confirm the current editor opens with zero existing SCU capacity; preserve the dated capacity inventory and editor screenshot. A docs citation alone is not an observed no-SCU launch.
2. Use only one known lab alert and minimal read permissions for the first integration. Inspect generated API hosts, methods and handling of credentials.
3. Record editor test for valid input and failure for unknown/malformed input. Confirm the alert/evidence IDs independently.
4. Capture what is actually visible: editor trace, saved code and runtime activity. Do not claim an incident comment if the workflow only reads data.
5. Keep editor testing distinct from enabled automatic-trigger testing. If a trigger is exercised, match its exact conditions to a controlled alert and capture the resulting activity.
6. No account disabling, device isolation, broad permission grant or external notification is needed to demonstrate generation. An optional narrowly scoped reversible comment must be labeled a write.
7. End with the created playbook/rule disabled unless continued operation is explicitly part of the chosen lab.

Screenshot targets: editor entry/permissions, prompt and resulting code/flow, valid/error test evidence, disabled saved object, runtime activity only if an automatic trigger actually runs.

3. Legacy risk-policy migration before October 1

Source nuance: The general configuration guide simplifies password versus passwordless outcomes; the concept page adds the important “compromised password involved” condition. Use the more explicit threat-dependent explanation. A confirmCompromised test does not prove the anomalous-token/no-password-compromise branch.

Proposed acceptance criteria:

1. Independently inventory the two legacy policies and all candidate CA replacements. If no legacy policies exist, call this a readiness demonstration—not migration of an active legacy deployment.
2. Compare include/exclude populations, resources, risk levels, grant/session controls and state. Separate security improvements from strict migration equivalence.
3. Capture report-only evaluation as evaluation, not enforcement; do not publish “blocked” from report-only results.
4. For an actual user-risk test, use a licensed disposable cloud-only user with a usable MFA/bootstrap path. Capture risk before/after, named CA policy result and visible remediation outcome.
5. Mark admin-injected risk in every relevant caption and table; it doesn’t validate organic detection or sign-in risk.
6. Confirm subsequent legitimate access, risk cleanup and restoration/removal of pilot policy effects.
7. Retire a real old policy only after the tested replacement is active. If old policy absent, this step is not applicable.

Screenshot targets: legacy-policy state, replacement policy scope/controls, report-only sign-in evaluation, actual remediation only if enforced and tested, final risk/user state.

4. Foundational CSPM opt-in before October 27

The opt-in notice explicitly says more transition information will be published nearer the date. A readiness script should return unknown when the actual free-plan signal cannot be established. Provider registration and recommendation rows are supporting evidence, not necessarily definitive state flags for every plan.

Proposed acceptance criteria:

1. Record subscription creation context, current free/paid plan presentation and corroborating API output.
2. Explain which exact field/control is authoritative for Foundational CSPM. If unclear, report uncertainty instead of creating a green result.
3. Check provisioning templates for explicit posture intent; preserve evidence of missing configuration as a readiness gap, not an observed service outage.
4. Test inventory logic against labeled enabled/disabled/unknown fixtures without switching off working protection.
5. Keep October27 behavior labeled documented future change; a post-cutoff new subscription is a separate later validation.
6. Avoid pressing “Enable all” to establish the free baseline; no paid expansion is necessary for this article.

Screenshot targets: current subscription’s plan page distinguishing free and paid CSPM, a scoped configuration/report excerpt, and the dated source timeline. Do not fabricate a future-new-subscription screenshot.

5. memberOf retirement before November 3

Proposed acceptance criteria:

1. Inventory all three surfaces. Store completion status, pages/counts and any permission errors for each.
2. For no matches, preserve an explicit successful zero-result artifact; distinguish unsupported/inaccessible/licensing-unavailable.
3. For each detected rule, map downstream application, licensing, CA or administrative scope and determine intended membership.
4. Test a supported replacement with harmless accounts. Show both a joiner gaining membership and a leaver losing it, using actual propagation evidence.
5. Compare expected, retained-unexpected and missing-intended users independently. Attribute drift to observed behavior without assuming cause.
6. Validate downstream scope where feasible; membership parity alone doesn’t prove a token, resource session or application authorization has converged.
7. If no equivalent rule exists, describe an assigned-membership/other operational alternative with an owner and update process. Don’t label it automatic equivalence.

Screenshot targets: three-surface discovery results, one rule/editor and supported replacement, before/after member differences, actual processing state. November freeze/quarantine remains a source-backed future statement.

Shared publication gates

• Caption every screenshot with what it demonstrates and when captured. Hide irrelevant tenant/user identifiers and all secrets.
• Do not combine nonconcurrent screenshots into a claimed single workflow.
• “I tested five changes” requires five corresponding outcome claims. If only configuration/readiness was inspected for some, title the piece around five checks.
• Preserve failed/partial results; absence of enforcement or event data is a finding with limits.
• Keep full private lab IDs/timestamps for traceability and publish sanitized evidence.
• Capture cleanup states for temporary identities, role assignments, policies, groups, playbooks, rules and integrations created during the lab.
• No source in this ledger requires Security Copilot capacity to be recreated for these five topics.

Expanded guide source check — September 11, 2026

The revised article leads with product changes and practical preparation. Detailed observations remain in the linked lab records. These additional Microsoft sources were rechecked for the expanded explanation:

• August Defender news: generation, testing, and execution of the Sentinel generator playbooks consume no SCUs.
• Sentinel application card: generated Python executes in a managed Sentinel environment.
• Generator introduction: Integration Profiles and the plan/code/documentation/diagram authoring model. Its older Security Copilot prerequisites are superseded by the August access announcement and current generator guide.
• Current generator guide: authoring and rule permissions, disabled initial state, enhanced alert triggers, runtime limits, and Activities-tab results. The proposed phishing-enrichment pilot is an editorial example.
• Risk-policy concepts: user risk versus sign-in risk, threat-dependent remediation, guest limitation, and policy precedence.
• Supported dynamic rules: attribute-based rules and the security implications of attribute write permissions. The Finance rule is illustrative, not a universal memberOf translation.
• Azure CLI pricing commands: plan-list query and explicit subscription selection. The example performs a read only.
• Defender for Cloud in Defender portal: cloud experiences, cloud scopes, phased onboarding and licensing prerequisites. The October 27 recommended-experience date comes from the separate Foundational CSPM opt-in notice, not an assertion of free-plan access to every current portal capability.

The article keeps five primary topics. Adaptive risk remediation and the Defender portal transition deepen the related retirement/default-change sections. No additional lab runs or new tenant outcomes are asserted by this revision.