Privacy-First Authentication for Businesses: Choosing Between Passkeys, MFA, and Identity Proofing

Overview

Authentication answers the question, “Can this user access the account?” Identity proofing answers a different question: “Is this person who they claim to be?” Keeping those purposes separate helps businesses avoid collecting identity documents or biometric information when a strong login control would be sufficient.

Passkeys use public-key cryptography and are designed to authenticate a user through a device-based credential. The local unlock step may involve a device PIN, fingerprint, face recognition, or another platform method. The business generally receives an authentication result rather than the user’s local biometric data. Passkeys can reduce reliance on passwords and phishing-prone codes, but account recovery and device enrollment still require careful design.

MFA requires two or more authentication factors, typically combining something the user knows, has, or is. The strength of MFA depends on the factors and how they are delivered. A hardware security key and authenticator-generated code do not present the same risks as a password combined with a code sent through a potentially vulnerable channel. MFA remains useful where passkeys are not yet supported, during migration, or for recovery and administrative controls.

Identity proofing is a higher-friction process that may involve a government identity document, a selfie or liveness check, database checks, business records, or human review. It is appropriate when the business needs evidence about a person’s real-world identity, eligibility, authority, or relationship to an organization. It should not be treated as a universal replacement for authentication: a verified person can still lose control of an account.

Checklist by scenario

1. Routine customer or employee sign-in

• Start with a passkey-first option where the relevant browsers, operating systems, and applications support it.
• Offer a carefully selected MFA alternative rather than forcing every user through identity proofing.
• Define the minimum account data needed for enrollment, notification, fraud analysis, and support.
• Set clear controls for new-device enrollment, session expiry, suspicious sign-ins, and inactive accounts.
• Make the recovery path no easier to defeat than the primary login path.

2. Administrator, finance, or privileged access

• Require phishing-resistant authentication where practical, with passkeys or approved hardware-backed methods.
• Separate ordinary user access from administrator access and apply stronger controls to both.
• Use step-up authentication before changing payment details, exporting sensitive data, changing access policies, or adding an administrator.
• Maintain more than one controlled recovery route so a lost device does not create an unmanaged emergency account.
• Log enrollment, factor replacement, recovery, and privilege changes for later review without storing unnecessary authentication secrets.

3. High-value onboarding or regulated workflows

• Decide whether the risk requires identity proofing, business identity verification, or both.
• Specify what must be verified: legal name, age or eligibility, authority to act, organization affiliation, beneficial ownership, or another defined attribute.
• Use proportional checks. A document and selfie review may be excessive for a low-risk account but justified for a high-value transaction or sensitive recovery.
• Define manual-review triggers for document inconsistencies, unusual device signals, repeated attempts, or mismatched identity attributes.
• For business onboarding, separate the individual’s authentication from KYB, UBO verification, sanctions screening, and other compliance checks. A successful login does not establish that a business is legitimate or that a person is authorized to represent it.

For related operational controls, see the KYC and KYB API integration blueprint and the beneficial ownership verification workflow.

4. Account recovery and device loss

• List every recovery method, including support-assisted recovery, backup codes, email changes, phone changes, and trusted devices.
• Rank each method by assurance and remove routes that bypass the strongest enrollment controls.
• Use delays, notifications, transaction limits, or secondary review for high-risk recovery events.
• Require evidence of account control rather than relying only on easily exposed profile information.
• Document how a user can revoke a lost device or compromised factor and how quickly the change takes effect.

What to double-check

Before selecting an authentication provider or changing a workflow, complete a short privacy and security review.

1. Purpose: Write down whether the control is authenticating an account, preventing fraud, proving identity, meeting a compliance requirement, or enabling a sensitive action. Do not use identity proofing to solve a problem that is actually weak session management.
2. Data flow: Map what is collected, where it is processed, which vendors receive it, and what the business retains. Include device identifiers, IP data, authentication events, documents, facial images, support records, and fraud signals where relevant.
3. Biometric exposure: Confirm whether biometric matching occurs locally on a device or whether biometric images or templates are sent to a service. Ask what happens during fallback, recovery, accessibility exceptions, and device changes.
4. Retention and deletion: Set retention periods by data type and purpose. Authentication logs, proofing evidence, support tickets, and fraud-review records may need different treatment. A vendor’s default retention setting is not a complete retention policy.
5. Security controls: Review encryption, access controls, tenant separation, audit logs, incident handling, administrator permissions, and export or deletion capabilities. Security attestations can support due diligence but should not replace a review of the actual integration.
6. User experience: Test enrollment, sign-in, recovery, device replacement, accessibility, shared-device scenarios, and users who cannot use a particular factor. Measure where users abandon the process and whether support staff receive enough context to resolve issues safely.
7. Decision quality: Define what happens when signals conflict. A failed proofing attempt, an unfamiliar device, or a name mismatch should lead to a documented review path, not an unexplained permanent rejection.

For an audit-oriented record, retain the decision rationale, configuration version, approval owner, vendor terms, test results, and evidence of periodic review. The identity verification audit-readiness checklist can help organize this evidence.

Common mistakes

• Confusing verification with authentication: Identity proofing establishes a point-in-time claim. It does not prove that the same person controls the account later.
• Assuming every MFA method is equally strong: Evaluate the actual factor, enrollment process, recovery process, and resistance to phishing or interception.
• Making recovery weaker than login: Attackers often target email changes, support workflows, backup codes, or factor replacement rather than the primary authenticator.
• Collecting identity documents by default: Excess data increases privacy, security, support, and deletion responsibilities. Collect proofing data only when the risk or obligation requires it.
• Ignoring migration and fallback: A strong new method can be undermined by an old password-only route left active indefinitely.
• Overlooking vendor and subprocessor changes: Authentication and identity platforms can change supported devices, processing locations, retention settings, or recovery behavior. Include these changes in supplier reviews.
• Treating a fraud score as a final decision: Risk signals should support a defined decision process, with escalation and human review where the consequences justify it.

When to revisit

Review the authentication design before seasonal planning cycles, major product launches, and changes to browsers, operating systems, authentication standards, identity providers, or recovery tooling. Revisit it after an account-takeover incident, repeated recovery abuse, a material change in transaction value, or the addition of a high-risk workflow such as investor onboarding, business payout changes, or privileged administration.

At least during each scheduled access-control review, work through this action list:

1. Inventory every login, step-up, enrollment, and recovery path.
2. Classify each workflow as routine, sensitive, privileged, or identity-critical.
3. Choose the lightest control that meets the documented risk: passkey, MFA, step-up authentication, or identity proofing.
4. Test lost-device, fallback, accessibility, and support-assisted recovery scenarios.
5. Recheck data minimization, biometric handling, retention, vendor access, and deletion procedures.
6. Record changes, owners, evidence, unresolved exceptions, and the next review date.

A privacy-first authentication program is not a single product decision. It is a maintained set of controls that protects access, limits unnecessary identity collection, and applies stronger proof when the consequences of error are higher.