Passkeys, MFA, and passwordless describe related but different aspects of authentication.
Learn the method, the policy requiring it, and the enrollment and recovery process before comparing every product feature.
For an IAM beginner, the useful goal is a complete explanation of one supported sign-in scenario. You should be able to distinguish having a method available from requiring an appropriate control for a particular attempt—and recognize what happens when the user needs recovery.
MFA describes the use of multiple authentication factors
Multifactor authentication combines more than one factor category in the authentication process, rather than relying only on a single secret such as a password.
The user experience and security properties depend on the methods and implementation. Two methods should not be assumed equivalent merely because both are called MFA.
Microsoft's authentication overview describes supported methods and distinguishes phishing-resistant approaches.
For learning, ask what is being proven, how the proof is checked, and which access policy requires it in the particular scenario.
Passwordless describes a sign-in experience without entering a password
Passwordless is a broad category, not one protocol or one product.
Different implementations can use different credentials and user-verification methods. A passwordless experience does not remove the need to understand enrollment, device handling, recovery, and authorization.
The term also does not mean the user receives unlimited access after signing in.
Keep the method and the resulting access decision separate. A successful authentication still needs to connect to the application's intended permissions and the policies governing the resource.
Passkeys use public-key cryptography for authentication
FIDO describes passkeys as credentials that use cryptographic key pairs for passwordless, phishing-resistant sign-in. They can be synced across devices or bound to a particular device, depending on the implementation.
The service receives proof associated with the credential rather than the user typing a reusable password into that service's login form.
Local user verification may involve a PIN or biometrics. FIDO's specification overview explains that biometric information, when used, remains on the user's device.
Do not reduce the explanation to “your fingerprint becomes your password.” That hides the cryptographic relationship that makes the method different.
Separate having a method from requiring it
A registered method doesn't, by itself, establish which access attempts must use it.
For the scenario you're studying, answer:
- Registration: How is the credential or method established for the user?
- Availability: Under what conditions may the user use it?
- Enforcement: Which policy or requirement applies to the particular sign-in?
- Evidence: What shows the relevant requirement was evaluated?
The details vary by platform and configuration. Check current supported documentation before designing a test.
Use the distinction between enrollment and enforcement to keep the exercise focused on actual access behavior. A rollout can produce a list of configured methods without demonstrating the intended requirements.
Record what your specific user, application, and test conditions establish. Don't infer complete authentication protection from one registration screen or a single successful prompt.
Recovery belongs in the learning plan
Ask what happens if the user loses a device, replaces a credential, or cannot complete the normal sign-in process.
A recovery path needs an appropriate way to establish the user's identity and restore access under the organization's policy. It should not casually bypass the protections the normal sign-in was intended to provide.
For a beginner lab, document the supported recovery options and the assumptions you are making. Do not experiment with real accounts you cannot safely recover or publish recovery secrets in the project.
Build a small comparison you can explain
Choose one supported test scenario and document the registration, sign-in, relevant policy, and recovery considerations.
State which behavior you actually tested and which you only researched. Avoid claiming that one successful demonstration proves every method is supported on every device or application.
The useful outcome is a clear explanation of the method and lifecycle, not a list of fashionable authentication terms.
The Six-Figure IAM Career Playbook helps organize identity fundamentals, practical labs, and career positioning around a target role. The $9 guide gives the learning a direction before the terminology becomes overwhelming.
Learn what the method proves, when it is required, and how it is managed over time. The product details are easier to understand once those questions are clear.