What counts as a factor?

The main categories are something you know, something you have and something you are. A password and a second memorised answer are both knowledge factors; two screens do not necessarily mean MFA.

Authentication establishes control of credentials associated with an account. Authorisation determines what that account can do afterwards. Strong sign-in does not, by itself, limit excessive permissions. Digital Identity Guidelines: Authentication and Authenticator Management — HTML

What changes with a passkey?

A passkey uses a cryptographic key pair rather than a password shared with the service. Some passkeys are synced between devices through a provider; others remain bound to a particular device, including suitable security keys. These arrangements create different questions about availability, management and recovery. FIDO Passkeys: Passwordless Authentication

A local PIN or biometric check can activate an authenticator. It is not simply another password being sent to the website. Whether the complete sign-in meets particular MFA or assurance requirements depends on the implementation and required verification. Digital Identity Guidelines: Authentication and Authenticator Management — HTML

Understand the limits

Phishing-resistant authentication is designed to resist a fraudulent service obtaining a usable authentication result. That does not establish protection of a compromised device, an existing application session or an account-recovery process. Different MFA methods have different properties; do not assume an SMS code and a phishing-resistant method provide equivalent protection. Digital Identity Guidelines: Authentication and Authenticator Management — HTML

These limits are reasons to plan the surrounding process. They are not a reason to postpone account protection indefinitely. ACSC provides introductory MFA guidance and links to official service instructions. Use instructions for the service you actually have. Multi-factor authentication

An invented lost-phone example

An employee uses a phone for work sign-ins and then loses it. The business has documented which administrator handles recovery and which approved alternative the employee can use. The administrator follows the organisation’s identity checks and reviews the lost device’s access through the appropriate platform process.

This scenario describes a plan, not a tested recovery procedure. It deliberately does not assume that a colleague should share an account or that every service uses the same recovery steps.

Questions before adoption

Use this planning checklist with the person responsible for identity management:

  • Which accounts and devices need to be supported?
  • What is the approved sign-in method, and what alternatives are accessible to staff?
  • Who controls credential sync and recovery accounts?
  • What happens when someone loses a device, changes role or leaves?
  • How is emergency administrative access handled?

Do not assume a work credential may be synced to a personal account. Make that an explicit organisational decision, with privacy and accessibility input where needed.

Optional depth: assurance and compatibility

NIST SP 800-63B-4 defines requirements for authentication assurance levels within its digital-identity framework. A passkey label alone does not establish an assurance level. Digital Identity Guidelines: Authentication and Authenticator Management — HTML

Before a rollout, ask an identity specialist to assess the chosen service, platform versions, recovery routes and shared-device needs. No particular browser, operating system or account configuration is validated by this article.

  • Recognizing and reporting suspicious messages — Recognise deceptive requests.
  • Employee onboarding, role changes and offboarding — Plan access through employment changes.
  • Least privilege and access controls — Distinguish sign-in from permissions.