Microsoft’s Sept 1 passkey email omitted the Graph opt-out. It is only in the FAQ. Decide before Tuesday.

Most IT managers who opened Microsoft’s passkey campaign email this month filed it as a September 1 MFA deadline. That reading is wrong in both directions: SMS and voice do not retire on Tuesday, and the only documented way to keep Microsoft from auto-enabling passkeys and flipping your registration campaign to Microsoft-managed is not in the email at all.

Here is the decision we are walking tenants through eight days out — what the message said, what the FAQ actually documents, and the three places a default-accept or a rushed opt-out will bite.

The email that started a campaign, not a retirement

Microsoft’s public timeline is two dates, not one. Beginning September 1, 2026, users still enabled for SMS or voice in the Authentication Methods Policy (or leftover legacy MFA settings) are auto-enabled for passkeys, and Registration campaign is moved to a Microsoft-managed state that targets those users. The next time they complete MFA, they get a passkey nudge. By default they can snooze it without a cap. Microsoft-provided SMS and voice retire on February 1, 2027. After that date, a user whose only remaining MFA method is SMS or voice hits a blocking passkey registration prompt. There is no opt-out for February.

The temporary hold lives in the Learn FAQ (and the same Graph snippet is now on the retirement article): PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy and set optOutSettings.passkeyDynamicMigration to true. You need Policy.ReadWrite.AuthenticationMethod. After that, the tenant is excluded from the automatic September enablement and campaign flip until February 1, 2027. The property does not keep Microsoft-provided SMS alive past that date, and it does not appear as a portal toggle next to Registration campaign.

What breaks it:

• Read the FAQ, not just the email — search passkeyDynamicMigration on Learn before you tell leadership “there is no off switch.”
• Inventory SMS and voice users first — Microsoft’s entra-sms-voice-usage-analyzer script is the scoped list. A non-zero result means you are in the September campaign whether or not those users already have Authenticator.
• Decide accept vs opt-out per tenant this week — Tuesday is the campaign start, not the retirement. An absent property or anything other than true means Microsoft will apply the automatic rollout.

The campaign you accept without an AAGUID or a helpdesk script

If you leave the opt-out unset, Microsoft puts in-scope users into a passkey profile that allows all types of passkeys: device-bound (Authenticator, Entra Passkey on Windows, FIDO2 hardware) and synced passkeys in a platform credential manager. That is a policy change plus a campaign scope change. It does not mint a credential. The user still registers — or postpones — at a later MFA sign-in.

Helpdesk will hear “it asked me to create a passkey” from people who already have Authenticator, from shared-device floors, and from phones that offer iCloud or Google Password Manager if you never constrained AAGUIDs. System-preferred authentication will not create the passkey; it only offers a method already registered. A campaign you set to Enabled and pointed at Authenticator is a different control than Microsoft-managed — and you still owe February a real method.

What breaks it:

• AAGUID allow-list on passkeys (FIDO2) — decide Authenticator-only vs hardware vs synced before the first nudge, not after the first ticket.
• A helpdesk script for the registration prompt — snooze is unlimited by default; “click Skip” is not a rollout. Tell them who must register this week, on which device, and who is excluded.
• Move users out of SMS/voice in AMP if they should not be in scope — Authenticator already on the phone does not remove them from the September targeting.

The door that stays open: break-glass still on SMS

The adjacent problem in every tenant we assess is the Global Admin that still signs in with a password plus a text message, or the only break-glass that is a synced everyday user. FIDO2-only emergency accounts with no password are the right shape. A Microsoft-managed campaign will not design that path; it will put a passkey prompt in front of whoever is still enabled for SMS.

If the only person who can recover Conditional Access is still on telecom MFA, Tuesday is not your problem — February is, and so is the next lockout. Do not leave the only GA as a synced mailbox with SMS. Register hardware-bound FIDO2 on a key that lives in the fire safe, drop the password if your operating model allows it, and keep that account out of the everyday user campaign.

What breaks it:

• FIDO2-only break-glass, stored offline — at least two keys, two people, no SMS, no Authenticator push on a daily phone.
• Privileged roles out of the SMS/voice AMP groups — campaign targeting is not an emergency-access design.
• A written exit from the Graph opt-out — if you PATCH true this week, calendar the work that must finish before February 1. The setting expires as a shield whether you remember it or not.

What "good" looks like: the five-item baseline

If you do nothing else before Tuesday, these five moves put the campaign, the FAQ switch, and break-glass in a state you can defend:

1. SMS/voice inventory — run the usage analyzer; treat any hit as campaign-in-scope.
2. Accept or opt out, in writing, per tenant — either leave Microsoft-managed on and staff the nudge, or PATCH optOutSettings.passkeyDynamicMigration to true before September 1.
3. Passkey (FIDO2) method policy you actually chose — AAGUID allow-list, Authenticator vs synced, self-service setup on for the people you intend to register.
4. Helpdesk script and user comms scoped to that inventory — not a tenant-wide “MFA is changing Monday” blast.
5. Break-glass on hardware FIDO2 — then confirm no remaining GA can be signed in with Microsoft-provided SMS alone.

None of this needs a new SKU. The Graph property is documented on Learn. The February date does not move if you opt out. Microsoft’s current articles point to September 18 for Security Store telecom details and October 30 for configure-and-buy — plan passkeys for everyone else.

The uncomfortable question

The question is not “do we support passkeys?” Most tenants already do for someone. It is: on September 2, who will have been auto-enabled, what AAGUID will they be allowed to register, and can we still recover the tenant if the only Global Admin is still waiting on a text message?

If you cannot answer that from the authentication methods policy, the registration campaign state, and the SMS/voice inventory, Tuesday will answer it for you.

The Copilot web host also moved this month — allowlist copilot.cloud.microsoft before the redirect blanks a workstation.