Restrict Microsoft 365 trust-enrollment and session-persistence paths

The packet’s July 10, 2026 Roundtable discussion treats Microsoft 365 identity as an active fault line: the cited synthesis says the decision point is which trusted paths must be cut or constrained before attackers turn them into durable access.

The identity architect and moderator both describe a shift from password theft to attacker-approved authority through enrollment, OAuth/device-code flows, tokens, cookies, authentication-method registration, and collaboration tooling.

The evidence review supports acting on those controls now while keeping campaign names source-reported. CVE-2026-50656 is named in the selected anchor, but the packet support for urgency here comes from Microsoft 365 trust-enrollment and session-persistence evidence, not from that CVE.

Microsoft 365 tenants using Microsoft Entra identity are affected when users can add passkeys, security keys, authenticators, phone methods, or recovery methods without managed-device, trusted-network, or verified help-desk controls.

High-risk users are specifically exposed because attacker-managed enrollment can create durable access even after a password reset. Help-desk teams are affected where workflows can be socially engineered into approving recovery or authentication-method changes.

Operators that allow broad device-code authentication are exposed to device-code abuse described in the packet.

Tenants with OAuth grants, refresh tokens, mailbox forwarding or rules, SharePoint/OneDrive bulk downloads, or Teams-to-extension workflows need review because the cited discussions tie those paths to persistence, data access, and collaboration-tool abuse.

CVE-2026-50656 is present as a selected anchor, but no affected Microsoft 365 identity population is established from that anchor in this packet.

The final synthesis says identity is a live fault line and calls for cutting or constraining trusted paths before attackers turn them into durable access; it specifically references fake Entra passkey enrollment as part of that identity lane.

The identity architect’s discussion supports the trust-enrollment framing: it describes Forg365 as source-reported AiTM and device-code phishing with token, cookie, OAuth/SMTP, mailbox-monitoring, and ForgCookie persistence, and O-UNC-066/Pink as source-reported vishing plus fake Microsoft Entra passkey enrollment.

The moderator’s discussion supports the practical shift from stolen passwords to stolen authority through tokens, cookies, authentication-method registration, OAuth/device-code flows, and collaboration tooling.

The defense architect’s discussion supports the response steps: review Entra passkey registrations, OAuth grants, mailbox rules, and revoke refresh tokens. The evidence review supports the operational controls and separately flags that named campaign details are not independently reconstructed here.

The Roundtable moved this into an operational identity-control decision after the identity architect framed Forg365, O-UNC-066/Pink, Helix-style device-code abuse, and Teams/Edge-extension lures as attacker-managed trust enrollment and session persistence, not only stolen-password phishing.

The moderator preserved the key boundary: the issue is attacker-controlled enrollment and durable sessions, not that passkeys are inherently weak. The defense architect separately prioritized revoking suspicious sessions, refresh tokens, OAuth grants, mailbox rules, and added authentication methods.

The evidence review found the Microsoft 365 control sequence supportable, while warning that named campaign details remain source-reported because primary campaign reports or tenant telemetry were not present in the packet.

The linker found no existing target, and the arbiter selected a new operational-action record.