The Scattered Spider playbook starts with a phone call. As a recent Infosecurity Magazine article explains, attackers research an employee, call the help desk, and persuade someone to reset a password or replace an authentication factor by authorizing a new passkey on any device including a bad actors own phone. The business may have strong security at login, but the attacker never needs to defeat it. The attacker convinces the business to enroll their device instead.
The FBI and its international partners have documented that pattern. Scattered Spider actors have persuaded support staff to transfer multifactor authentication to devices they control, then used those devices to enter single sign on environments. If an attacker can replace your authenticator through a convincing conversation, your strongest login method becomes optional.
The answer is to make the company issued Token device a mandatory condition of entry. Configure the identity provider to accept only approved, device bound Token authenticators. Enforce attestation to only allow the Token AAGUID so a synced passkey from a personal phone, a cloud account, or an unknown computer cannot become an accepted substitute. Apply that rule to both registration and sign in. Microsoft documents these AAGUID and attestation controls. No Token device, no entry.
AAGUID is the first gate. It locks down an authenticator model, not the particular unit assigned to an employee. The application also registers that employee’s Token credential and verify its cryptographic signature at every login. The issuance record should connect the employee, the physical device, and the credential stored in the identity system. A stranger holding another device of the same approved model is refused.
Then require the rest of the chain. The employee must use their own Token device and verify their fingerprint on it. The Token must be physically near the computer or smartphone initiating the login, with a target distance of about three feet. The authentication must be bound to the original registered domain, so a lookalike site cannot collect a reusable code or trick the device into signing for the wrong destination. The server verifies a fresh cryptographic response from the registered credential. A copied identifier or a persuasive voice cannot provide one.
That changes the economics of the attack. Social engineering can obtain facts, convince someone to approve a push request, or get a code read aloud. It cannot make an unissued authenticator hold the private key already registered to a specific employee. Without the approved device in the employee’s hand, the required fingerprint, and the registered domain, the authentication transaction does not complete. The system makes an answer that sounds plausible irrelevant; it waits for proof. The help desk cannot manufacture that proof by editing a ticket.
This distinction matters for passkeys. FIDO passkeys can be phishing resistant, and many are acceptable for consumer accounts. Many are synced across devices through a personal cloud account. Others live on a specific phone or computer. If the company wants access tied to hardware it issued and controls, it must enforce that choice in policy. An approved AAGUID with attestation can exclude unapproved authenticator types and synced credentials. The employee specific credential check then ensures that only the assigned Token works for that account.
The rule must follow the user across the business. Protect single sign on, remote access, administrator consoles, and sensitive applications that permit direct login. Include contractors and outside support personnel. Review old authenticators and remove fallback routes that allow a password, text message, push approval, or personal passkey to satisfy the same access requirement. One unprotected application can undo the rule everywhere else.
Account recovery is where this design is tested. A help desk agent can report a lost device and revoke its credential (though its unusable anywhere without the correct fingerprint). That agent should not be able to waive the Token requirement because a caller sounds credible or has personal details. Give employees a second company issued device registered in advance when continuity is essential. If both devices are lost, require controlled identity proofing, separate approval, an audited replacement, and notice through an existing channel. Keep protected access suspended until the replacement is securely registered. NIST identifies account recovery as a common weak point.
The same discipline applies to the administrators who can change authentication policy. Their access must require approved devices too. Emergency access should be very narrow, monitored, and protected from a single person’s decision. The organization also needs to test the actual login flow, including mobile access and every fallback screen. A policy that looks strict in a dashboard is only as strong as the paths it really blocks.
This does not eliminate every cyber risk. It does directly close the account takeover route Scattered Spider favors: persuading a person to swap in an attacker’s factor. The decisive question is whether anyone can enter, enroll a replacement, or recover an account without the employee’s approved Token and a secure process. If the answer is yes, the door remains open.