Authenticator codes or passkeys: what changes when you sign in?

An authenticator code and a security key can look like two ways to complete the same sign-in prompt. Underneath, they prove different things. That difference matters when someone enters their credentials on a convincing fake login page.

NIST recommends phishing-resistant authentication where available. Passkeys and FIDO security keys use cryptographic authentication tied to the legitimate service. A code typed into a web page lacks that same binding, even when it expires quickly.

The protection has a defined scope. Recovery procedures, devices, administrator access and sessions already established after login can still give an attacker another way into an account.

What your authenticator app is calculating

Time-based one-time passwords, or TOTP, derive a short code from a shared secret and the current time step. The authenticator and verifier hold the information needed to calculate the expected value. RFC 6238 recommends a 30-second default step, although implementations and accepted timing windows vary. Clock drift and acceptance windows therefore matter when diagnosing failed codes.

RFC 6238: the TOTP authentication algorithm

A valid TOTP code shows access to the shared secret during the accepted time interval. It carries no cryptographic proof of which website received it. That is why ordinary authenticator codes are not phishing-resistant. Protect the enrollment QR code as carefully as a credential: someone who obtains its secret may be able to generate future codes.

NIST distinguishes phishing resistance from resistance to replay and requires one-time acceptance of valid OTPs. Short validity is useful, but a rapidly expiring code still has different protections from an authenticator that binds its response to the legitimate verifier.

NIST SP 800-63B-4: authenticator requirements

How WebAuthn checks the site as well as the credential

With WebAuthn, a service registers a public-key credential. At authentication, the authenticator produces a signed response to a fresh challenge; the service verifies it against the registered public key and expected context. The relying-party identifier, browser origin, challenge and authenticator flags are part of the validation model. The private key is not submitted as a password to the website.

W3C WebAuthn: public-key credentials and verification

A credential registered for one service cannot normally produce a valid login assertion for that service from an unrelated phishing origin. The server still has work to do: it must validate the challenge, origin, relying-party identifier and other required context. Merely adding a WebAuthn prompt does not make those checks optional.

A touch and a PIN or biometric also serve different purposes. Touch can demonstrate that someone is interacting with the authenticator. A PIN or biometric can verify that user locally, where the authenticator and policy support it. Whether a passkey meets a service’s multifactor requirements depends on the policy and how user verification is enforced.

Decide how you will handle a lost device

A hardware security key can keep a credential on that device. A synchronized passkey can be available through its provider’s synchronization and recovery system. These are different operational models: device loss, provider-account recovery, staff offboarding and backup enrollment need to be evaluated for the model actually chosen. Do not assume that every passkey lives on a removable hardware token.

Before rolling out the method, document the approved authenticators, user-verification policy, backup-factor ownership and recovery approval process. Enroll a supported backup before removing working access. Recovery needs comparable care: an easily abused recovery route can undermine a strong everyday sign-in.

After sign-in, the session still needs protection

After login, a service usually establishes an application session. Malware on the endpoint, unsafe application authorization and failures in session handling are separate concerns from credential phishing. A security key substantially improves the login boundary, but it does not make an already authenticated browser or an administrative recovery process immune to compromise.

Pair phishing-resistant sign-in with device updates, limited administrative privileges, session-revocation procedures and monitoring for changes to registered factors. Test enrollment and recovery with authorized accounts. Check that the policy is enforced, rather than stopping when a security key appears in the settings page.

Choose a method the service can support properly

Check where a passkey will live and which devices can use it. A synchronized credential brings the provider’s account recovery and synchronization system into the picture. A device-bound credential makes the loss or replacement of that device a more direct concern. Both choices need a clear offboarding process.

Authenticator codes and approval prompts can improve protection over a password alone, but ordinary code and push methods are not automatically phishing resistant. If a service does not yet support your preferred method, use its strongest suitable supported option and record the limitation.

Begin with accounts that can unlock others

Prioritize business email administration, your password manager, domain registration, and other critical administrator accounts. Review the provider’s supported methods and policies. A controlled pilot with a few authorized users helps you learn where enrollment, daily use, or recovery needs a clearer explanation.

• Confirm the legitimate service’s enrollment instructions.

• Choose an authentication method suited to the business and supported devices.

• Plan an approved backup or recovery route before changing access.

• Explain how users should report unexpected approval prompts or lost devices.

• Verify enrollment and policy coverage, including administrator accounts.

Finish the recovery plan

If one personal device is the only way back into a critical business account, there is still work to do. Protect recovery codes and contacts, follow the provider’s supported process, and document who can approve recovery.

Keep a working authentication method until the replacement has been confirmed. Arrange enrollment changes when an authorized person can help with failures, and revisit the recovery plan when devices, staff roles or providers change.

Sources & further reading

NIST: Multi-factor authentication, including passkeys and phishing resistance

CISA: Require multifactor authentication

Technical review: September 8, 2026. This is Short Circuit LLC’s original guidance, with primary sources linked beside the relevant explanations. Examples are illustrative.