Why do passwordless authentication and wallets still need extra controls?

Because strong authentication proves control of an authenticator, not approval of a specific action. Without binding, a legitimate-looking session can still be used to recover an account, approve a payment, or reattach a credential in a way the user did not intend. The gap is in action-level assurance, not only login strength.

Why This Matters for Security Teams

passwordless authentication and digital wallets reduce password reuse, phishing exposure, and help desk friction, but they do not eliminate the need to prove that a specific high-risk action was intended. A strong login can still lead to account recovery, payment approval, credential reattachment, or device enrolment if the downstream workflow is weak. That is why control design must move beyond session trust and into action-level assurance, transaction binding, and step-up verification. NIST guidance on access control and authentication boundaries in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it treats authentication as one part of a broader control objective, not the end state.

Security teams often assume that if the user has completed a phishing-resistant login, every subsequent action in that session is equally trustworthy. That assumption breaks down when a wallet, device passkey, or biometric factor is used to unlock a session that later performs irreversible actions. The real risk is session misuse after authentication, not only initial compromise. In practice, many security teams encounter abuse only after account recovery or payment fraud has already been completed, rather than through intentional design of step-up controls.

How It Works in Practice

The practical answer is to separate authentication from authorisation and to bind sensitive actions to explicit context. Passwordless methods such as passkeys, device-bound credentials, and wallet flows should confirm identity and possession, but high-risk operations still need an additional decision point. That decision point can be a re-prompt, biometric recheck, transaction signing, step-up MFA, or policy-based approval that includes the action, amount, destination, device state, and risk signals.

For practitioners, the important question is not “Did the user log in?” but “Did the user intend this exact action under these exact conditions?” This is especially important for account recovery, new device enrolment, adding a payment instrument, changing recovery contact details, or reattaching a credential. Controls should be designed so that the approved action is visible to the user before completion, and the system records the action context for audit and dispute handling. ISO control design in ISO/IEC 27001:2022 Information Security Management supports this mindset because governance, logging, and access decisions need to work together rather than in silos.

• Use transaction binding for high-risk changes so the approval is tied to amount, recipient, and purpose.
• Require step-up checks for recovery, enrolment, and credential lifecycle events, not just for login.
• Log action context, device posture, and risk signals so fraud teams can investigate intent disputes.
• Apply least privilege so a valid wallet session cannot reach sensitive functions by default.

Where wallets are used for payments or identity assertions, the session should be treated as an input to risk scoring, not a blanket approval for all downstream actions. This is consistent with modern control thinking in NIST and ISO guidance, and it aligns well with identity and NHI governance when autonomous agents or delegated workflows can act on behalf of a user. These controls tend to break down in heavily federated environments where multiple relying parties interpret the same authenticated session differently because action binding and risk signals are not consistently shared.

Common Variations and Edge Cases

Tighter action binding often increases user friction and recovery overhead, requiring organisations to balance fraud reduction against support cost and conversion loss. That tradeoff becomes more visible when the user experience depends on mobile devices, hardware tokens, or wallet ecosystems with different trust models.

There is no universal standard for how much extra control is enough in every wallet or passwordless flow. Current guidance suggests using stronger binding for irreversible, high-value, or identity-altering actions, while keeping low-risk actions as friction-light as possible. For example, a read-only dashboard action may not need the same controls as a password reset, beneficiary change, or wallet re-registration. The same applies when an AI agent or delegated workflow can trigger an action on a user’s behalf: the organisation should distinguish between authenticated delegation and explicit approval for the specific task.

Teams also need to account for edge cases such as lost devices, shared family wallets, high-risk geographies, and fraud patterns that exploit legitimate recovery channels. In those cases, “passwordless” does not mean “challenge-free.” It means the control stack has shifted from secret memorisation to stronger proof of possession and intent, with additional governance around exceptions. The most common failure is treating recovery and enrolment as administrative convenience rather than security-critical transactions, which creates a path for attackers to convert a valid login into lasting account control.

Related resources from NHI Mgmt Group

• Why does passwordless authentication still need MFA and session controls?
• Why do passwordless authentication programmes still need strong enrollment controls?
• Why do passwordless logins still need strong access controls?
• Why do password controls still matter in SSO and passwordless environments?