Session CRT-20260720 — 20 July 2026

Halil, brand matching is secondary here. The hard fact is simpler: one employee completed passkey enrollment during a fake IT-support call. According to Okta, this campaign tricks users into approving attacker-initiated Entra passkey registration, and Microsoft documents passkeys/FIDO2 as a sign-in method for Entra ID. So assume a spare key may have been cut for that account. Not “maybe they know the password” — an authentication method may now exist that lets someone sign in as the user.

What I’d use to separate attacker-controlled enrollment from failed or user-controlled enrollment:

• Entra authentication methods: did the user’s registered methods change around the call time, especially showing FIDO2 security key / passkey and a new “Last Updated Time”? Microsoft’s authentication-methods activity report exposes registered methods including FIDO2.
• Sign-in logs: after enrollment, do we see successful sign-ins where authentication details show the method sequence using passkey/FIDO2, from unfamiliar IP, device, location, or user agent? Microsoft notes sign-in logs include authentication-method sequence, though details can lag or be incomplete initially.
• Device registration / Intune: any new Entra or Intune device registration near the call? MITRE specifically calls out adversaries registering devices in Entra/Intune to access resources or bypass conditional access. If that appears, the chain is closing.
• M365 activity: after the enrollment, look for Exchange, SharePoint, OneDrive, Teams, or Graph activity inconsistent with that user — especially search, mass reads, downloads, or access from the same new session. Okta says this activity is data-extortion motivated, so data access is the objective, not the trophy.

My threshold: targeted containment is enough only if you can prove the completed passkey is user-owned and there were no post-enrollment passkey sign-ins, no new device registration, and no abnormal M365 access. Otherwise, treat the completed enrollment as account compromise. For this case, I’d immediately contain both accounts: block sign-in or force secure recovery, remove the new passkey/FIDO2 method, revoke their sessions, and re-register auth methods through a trusted process. I would also run a tenant-wide passkey/FIDO2 enrollment audit now. I would not revoke every tenant session yet unless the audit finds more suspicious enrollments or post-enrollment access. Don’t carpet-bomb the building unless smoke shows up outside these two rooms.

Halil, operationally the match is strong on tradecraft, but only moderate for attribution. Fake IT support + Entra passkey enrollment + a completed attacker-controlled enrollment lines up closely with Okta’s O-UNC-066/Pink reporting: vishing, passkey-themed domains/pages, Microsoft-branded lure flow, and the “recovery key” distraction while the actor registers their own passkey. I would not call this Pink with high confidence unless we see infrastructure/panel/domain overlap.

After takeover, the reported Pink/O-UNC-066 pattern is fast Microsoft 365 data theft: SharePoint/OneDrive access, cloud exfiltration, then data-extortion pressure, including Teams/email demands in some reporting. MITRE-wise, the key technique is T1098.005 – Account Manipulation: Device Registration.

My call: do identity/cloud IR tonight, but scope it tightly. One completed enrollment is enough to contain the user, revoke sessions/tokens, remove new auth methods/passkeys, review consent/device registration, and hunt SharePoint/OneDrive/Graph activity. It becomes a broader tenant campaign if we see clustered employee calls, multiple passkey/MFA enrollment attempts, tenant-branded phishing domains, repeated failed/successful auth from shared infrastructure, new auth methods across users, or abnormal SharePoint/OneDrive download activity. Without that, two calls are not enough for tenant-wide attribution or breach assumptions.

My call: treat this as targeted account takeover until the audit proves it is broader. In the first 30 minutes, contain the two users only: for the completed enrollment, delete the newly registered passkey from the user’s authentication methods, revoke that user’s sessions, require password reset, and preserve Entra audit/sign-in evidence. For the interrupted user, check whether any passkey/FIDO2 method was actually added; if yes, same containment, if no, revoke sessions and force password reset but don’t wipe all MFA methods yet. Microsoft documents that admins can delete passkeys from the per-user authentication methods UI/API, and that “Revoke sessions” invalidates refresh tokens and forces reauthentication.

By 60 minutes, run a tenant-wide audit, not a tenant-wide revocation. Query Entra audit logs for “Add Passkey (device-bound)” events in the vishing window plus 24 hours before/after, and compare against helpdesk tickets, user geography, device, and sign-in anomalies. The Microsoft TechCommunity guidance shows FIDO2/passkey registrations create Entra audit events and gives the relevant operation name. This should be a high-signal hunt — expected false positives are low, maybe 1–3%, mainly legitimate helpdesk-driven passkey rollouts. By 180 minutes, expand containment only if the audit finds additional suspicious enrollments, privileged users touched, impossible-travel/token abuse, or mailbox/data-access activity after enrollment.

What I would avoid: don’t do tenant-wide session revocation just because two calls happened. That will force broad reauthentication and can create a helpdesk outage, especially for mobile, shared workstations, and service-adjacent users. Don’t delete everyone’s passkeys unless you have evidence the enrollment process or admin policy was compromised. The line is this: targeted revocation for the two known users immediately; tenant-wide audit immediately; tenant-wide session revocation only if the audit shows spread beyond the two-account incident or privileged compromise.

Halil, my SOC decision is: do a tenant-wide audit of passkey/TAP/authentication-method changes, but revoke sessions only for the confirmed users plus a risk-defined cohort — not the whole tenant by default. The reason is that this campaign abuses the enrollment trust boundary, not the cryptography of passkeys themselves. CyberBrief reporting says the vishing flow tricks Microsoft 365 users into fake Entra passkey enrollment, with operators capturing credentials/MFA responses and in some cases registering an attacker-controlled passkey. So one completed enrollment is enough to justify looking tenant-wide for parallel attempts, but not enough to burn every user session unless logs show broader compromise.

Here is the checklist I’d give the SOC:

1. Authentication methods / passkey objects

   • Pull Entra Authentication Methods Activity for the affected user, the second contacted user, and then tenant-wide for the campaign window.
   • Look for newly registered methods: FIDO2 security key/passkey, Temporary Access Pass, Windows Hello for Business, Microsoft Authenticator passwordless, phone methods, and any unexpected method additions. Microsoft’s report explicitly tracks “Methods registered,” including FIDO2 security key and Temporary Access Pass.

2. Audit logs

   • Query audit events for:
     • User registered security info
     • Admin registered security info
     • Create Temporary Access Pass method for user
     • Result reason containing “User registered temporary access pass method”
     • Modified property display name: TemporaryAccessPass
   • For passkeys/FIDO2, correlate any new authentication method registration with timestamp, actor, IP, user agent, and whether the action was self-service or admin-initiated.

3. TAP use

   • Check whether a TAP was created, who created it, and whether it was used in a sign-in shortly afterward.
   • Elastic’s Entra detection guidance specifically recommends looking in sign-in logs where authentication_details contains “Temporary Access Pass” after TAP creation.

4. Sign-in logs, Conditional Access, and risk

   • For the affected users, review sign-ins around enrollment time for authentication details, IP/location changes, device details, user agent, Conditional Access result, CAE status, and risk.
   • Microsoft’s sign-in log documentation notes that sign-in details include Conditional Access and Continuous Access Evaluation context, and that some device-registration-related events appear as bootstrap scenarios. That matters here because enrollment attacks often hide in “normal” onboarding-looking flows.

5. Device registration / device trust

   • Check whether any new device registration, device compliance bootstrap, or Windows Hello for Business binding occurred near the passkey/TAP event.
   • If an unmanaged or unfamiliar device became trusted during the same call window, treat that as a persistence object, not just a login artifact.

6. Refresh tokens and session state

   • For confirmed compromised users, immediately block sign-in, remove the attacker-added method, reset credentials where applicable, and revoke sign-in sessions.
   • Microsoft Graph revokeSignInSessions invalidates refresh tokens issued to applications and browser session cookies by resetting signInSessionsValidFromDateTime, though Microsoft warns revocation can take a few minutes.
   • Also remember Microsoft’s emergency guidance: browser apps may maintain their own session tokens, so Entra token revocation is necessary but may not terminate every application session unless the application honors the revocation boundary.

On scope: do not revoke the whole tenant on day one unless you see tenant-wide method tampering, suspicious TAP creation by privileged admins, multiple successful passkey enrollments, impossible-travel/risky sign-ins across many users, or evidence the phishing operator had admin/control-plane access. Revoke sessions for the one confirmed user and the second targeted account if they interacted with the flow, then expand to a cohort: users who received the vishing call, visited the phishing domain, registered any auth method in the window, used TAP, had new device registration, or showed risky sign-ins.

My hard line: remove any newly enrolled passkey you cannot bind to a known user-owned authenticator, disable or tightly scope TAP, and freeze self-service passkey enrollment until enrollment is protected by strong helpdesk verification and phishing-resistant reauthentication. The passkey is strong after trust is established; this incident is about who was allowed to establish that trust.

I would not make tenant-wide session revocation the default. Microsoft says emergency revocation blocks new sign-ins and revokes refresh tokens for a user; access-token enforcement can depend on token refresh behavior, with standard access tokens valid for one hour unless CAE-supported enforcement applies. So the tradeoff is: targeted containment buys control with limited business interruption; tenant-wide revocation creates a deliberate authentication event across Outlook, Teams, SharePoint, mobile clients, and line-of-business workflows.

For planning, I’d present the cost as a model, not a sourced benchmark: users × lost time × loaded labor rate. If leadership assumes 60–120 minutes lost per user and $75–$125 loaded hourly labor cost, then a 10,000-user tenant is $0.75M–$2.5M of productivity exposure; a 50,000-user tenant is $3.75M–$12.5M. Those labor-rate and downtime inputs need validation against the company’s own finance data. Targeted two-user containment should be materially cheaper, but I would avoid a hard “tens of thousands” claim unless James gives the actual SOC/helpdesk staffing and duration.

I’d justify tenant-wide revocation anyway if the audit shows spread beyond the two users, privileged compromise, unauthorized auth-method or passkey changes, token replay from abnormal locations, or access into high-value data stores like Exchange, SharePoint, or OneDrive. Board version: don’t pay millions in controlled disruption unless there is evidence the attacker can reuse sessions at scale — but if that evidence appears, the disruption becomes the cheaper option.

Halil, on the facts given, I would have the SOC record this tonight as a confirmed security incident / credential-governance failure, not yet as a confirmed personal-data breach. The record should say: vishing-assisted Entra passkey enrollment completed; identity, device, IP, caller/social-engineering artifacts, Conditional Access results, MFA/passkey registration logs, sign-in logs, app consent/OAuth events, mailbox/file/API access logs, and any privileged-role activity are under legal hold. Governance action tonight: disable or revoke the rogue passkey, reset/re-proof the account, preserve logs before retention rollover, open an incident timeline, name Legal/DPO/Compliance owners, and explicitly record that notification clocks are being assessed from awareness of qualifying facts, not from patch completion.

For GDPR, the line is crossed when evidence shows a “personal data breach” with risk to individuals: for example, unauthorized access to mailbox contents, HR/customer records, files, tokens enabling access to personal data, or audit evidence that personal data was viewed, copied, altered, or made unavailable. GDPR Article 33(1), as reflected in EDPB guidance, requires supervisory-authority notification “without undue delay” and where feasible within 72 hours after becoming aware, unless the breach is unlikely to result in risk to individuals; Article 33(5) also means the assessment and evidence must be documented. Data-subject communication under Article 34 is a later, higher-impact question and should not be assumed tonight without evidence of likely serious impact.

For NIS2, do not trigger external reporting merely because one passkey was enrolled; the relevant threshold is whether an essential/important entity has become aware of a significant incident. EUR-Lex text for NIS2 describes an early warning within 24 hours, incident notification within 72 hours, and final reporting within one month for significant incidents. If this account is privileged, affects service continuity, enables lateral movement, or touches regulated operational systems, prepare the NIS2 notice pack now. For DORA-style operational resilience, I would preserve and classify now, but I cannot verify the current DORA reporting criteria or clocks from the available sources here, so I would not state a DORA notification deadline without checking the competent-authority route for the specific financial entity.

The case for full IR is when the first hour shows spread or control, not just one bad enrollment. CyberBrief reporting says this vishing flow can capture credentials/MFA in real time and enroll an attacker-controlled passkey for M365 account takeover/data extortion. So if we see successful post-enrollment sign-ins using passkey/FIDO2 from unfamiliar IP/device/location, that is no longer “user got tricked.” That is the attacker holding a working key to the house.

My hard escalation triggers: more passkey/FIDO2 registrations outside the two employees; any privileged account touched; successful authentication to Device Registration Service or new Entra/Intune device registration around the same window; Entra risky-user/high-risk events; or M365 audit activity showing mailbox, SharePoint, OneDrive, Teams, or Graph access after the new method was added. James’ defensive threshold matches mine: escalate on evidence of spread, control, or post-enrollment data access. At that point I’d activate full IR, revoke sessions beyond just the two users based on blast radius, remove suspect methods, block impacted accounts, and audit all recent authentication-method changes tenant-wide immediately.

What lets us hold the narrower line: the completed passkey is the only suspicious registration; no successful sign-ins using it; no new device registration; no privileged users or admin actions; no risky-user events; and M365 audit logs show no abnormal access after the enrollment. That is still ugly, but it is contained ugliness. Target the two accounts, revoke their sessions, remove the new passkey, force trusted re-registration, and keep the tenant-wide passkey audit running.