Authentication and Action Risk
The term "two-factor authentication" is technically correct and practically misleading.
Different authenticators provide distinct assurance and have specific failure modes.
Authentication requirements depend on context.
Begin with the action being authorized:
"Is the authentication strength proportional to the risk of the action being taken?"
Login, withdrawal, role changes and recovery each need authentication appropriate to their consequences.
Security-By-Design begins by rejecting one-size-fits-all controls.
Account Compromise Threat Model
Before comparing methods, it's worth being explicit about what we're defending against.
Account threats include phishing, reused credentials, session theft and recovery abuse.
Evaluate authentication against the attacks in the system’s threat model.
The effectiveness of a 2FA method depends entirely on which of these threats it actually mitigates.
Email Codes and Account Risk
Email codes can support address confirmation and account notifications. Authentication policy needs a separate assessment of factor independence, account recovery and phishing resistance.
An email-based workflow depends on the security of the mailbox, its recovery process, message delivery and any forwarding rules.
These assumptions are increasingly unsafe.
Compromised email can expose reset links, codes and notifications. Account protection should account for that dependency.
Use email for appropriate confirmation and notification purposes under the applicable authentication policy.
Email can confirm an address and deliver notifications. Sensitive access requires authentication matched to the action and its risks.
Email has specific confirmation and notification uses that need an appropriate risk assessment.
TOTP (Authenticator Apps): Still Useful, Still Misunderstood
Time-based One-Time Passwords (TOTP) represent a meaningful improvement over email codes.
TOTP adds a possession-based check to a password flow. Its secret may be stored locally or backed up by an authenticator service; real-time phishing can capture usable codes.
Because the secret is stored locally on the user's device, attackers need the local secret as well as a leaked password to gain access.
However, TOTP is not phishing-proof.
If a user is tricked into entering both their password and their TOTP code into a convincing phishing site, an attacker can still succeed—especially in real time.
The trade-off is recovery and usability. Device loss can lock users out, backup strategies are often unclear, and users regularly misunderstand setup and migration. A good platform reduces that pain with clear setup guidance and deliberate recovery requirements.
TOTP provides a changing code derived from a shared secret. Enrollment, storage, recovery and real-time phishing defenses affect its security.
Passkeys: A Fundamental Shift in Authentication
Passkeys use public-key authentication bound to a relying party.
Passkeys use a public-key credential bound to the relying party. Depending on the authenticator, keys may remain device-bound or sync through a protected service. Activation can use a PIN or biometric.
This changes the threat landscape dramatically.
Passkeys provide phishing resistance through verifier binding. Account recovery, endpoint compromise and authentication fallback remain important risks.
From a usability perspective, they feel simpler than passwords. From a security perspective, they remove entire classes of attack.
Passkeys are a useful option for phishing-resistant platform authentication.
Passkeys Within a Layered Design
Passkey deployment depends on device support, enrollment and recovery.
Passkeys depend on device availability, operating system support, and reliable backup/sync mechanisms. That's why recovery design still matters even in a passkey-first world.
They also introduce new questions around recovery when devices are lost or replaced.
Layer authentication methods according to their specific purpose and assurance.
Document the accepted methods for login, reauthentication and sensitive actions, with recovery requirements appropriate to each method.
Recovery and fallback methods need their own defined controls.
Migration path to passkeys: enroll a passkey, test supported devices and confirm the recovery method. Retain or retire other methods according to the account’s assurance policy.
Backup Codes and Recovery
Backup codes provide a recovery path and need protected storage, limited reuse and a clear revocation process.
They exist for one reason: when everything else fails.
Store backup codes securely and explain their recovery role. Copies accessible to an attacker create an account-access risk.
Used incorrectly—stored in inboxes, screenshots, or cloud notes—they become liabilities.
Explain backup codes as sensitive recovery credentials, with secure generation and storage.
They are boring—and that is exactly why they work.
Authentication Assurance Levels
One of the biggest mistakes platforms make is treating authentication as a static setting.
Match authentication requirements to the sensitivity of the action, its potential impact and the available recovery controls.
Viewing information, withdrawing assets and changing authority each carry distinct consequences.
A step-up design raises authentication requirements for sensitive actions. Assurance depends on the authenticator, its activation factors and the action being authorized.
This allows the platform to remain usable without sacrificing protection.
The Policy Ladder: When to Step Up, When to Block
Authentication policies should form a clear ladder: as risk increases, so should authentication requirements. This ladder is especially important for launch platforms where actions can have significant financial impact.
Low-risk actions (viewing account information, browsing launches) require only session authentication. Users who are already logged in can perform these actions without additional verification. This keeps the platform usable for routine activities.
For a sensitive action, select an authentication assurance requirement based on its consequences. A multifactor cryptographic authenticator can already combine possession and an activation factor; any additional step needs a defined purpose.
High-risk actions (large withdrawals, recovery changes, admin operations) require multiple independent factors and often include time delays. These actions are irreversible or have significant financial impact, so they require the strongest authentication and intentional friction to prevent rushed decisions.
When to block actions: require the specified authentication before authorizing a sensitive action. Explain the restriction and the approved recovery route.
A platform should document action-specific assurance requirements. Platform authentication governs its own services; authority over a connected wallet depends on the wallet and contract design.
When to Require Each Method (In Practice)
Select the assurance required for the current action.
Choosing the right method is a policy decision. For low-risk actions, a passkey or an active session can be sufficient because the impact is limited and reversible.
Sensitive participation, settings and transfer actions need assurance matched to their scope and consequences. Document reauthentication, authorization and recovery requirements.
For high-risk actions, select authentication and recovery controls according to the assessed assurance requirements. Consider authenticator properties, activation factors, session state and safeguards for account changes.
Low-risk actions may only require a passkey or session confirmation.
Sensitive actions may require reauthentication or additional assurance under the applicable policy.
High-risk actions—such as withdrawals, recovery changes, or role escalation—require multiple independent factors and often introduce time delays.
This approach aligns authentication effort with assessed action risk.
Recovery Is Where Authentication Is Truly Tested
Authentication systems are easy to evaluate when everything works.
They are exposed when something goes wrong.
Recovery can bypass normal authentication requirements. Assess the evidence required for recovery, abuse detection, user notifications and the permissions available during the process.
Recovery should define accepted evidence, risk-based delays, established-channel notifications and an auditable decision trail. Test the policy against account-takeover scenarios.
This protects users from rushed decisions and attackers from exploiting urgency.
Administrative and Privileged Accounts Require Stronger Rules
Account roles have different privilege and exposure.
Administrative accounts represent systemic risk: compromise affects other users. That is why strong authentication must be mandatory, email-only verification must be disallowed, recovery must be restricted, and every privileged action must leave an explicit audit trail.
In practice, this means enforcing phishing-resistant factors for admins, requiring step-up authentication for sensitive operations, applying intentional delays to high-impact changes, and using monitored approval workflows for the most dangerous actions.
Document the separation of authentication, authorization and recovery so an institutional reviewer can assess the relevant controls.
UX Determines Whether Security Is Followed or Bypassed
Test whether users understand authentication and recovery flows.
Security UX should explain additional steps, the relevant threat and recovery options in clear, contextual language.
Authentication flows should explain each security step in plain language at the point where the user needs it.
Users who understand why a step exists are far more likely to respect it.
Why Institutions Care Deeply About Authentication Design
Institutional reviewers can examine the assurance provided for each sensitive action.
They ask which methods are supported, when they are enforced, how exceptions are handled, and how recovery is controlled—because authentication design is a proxy for operational maturity.
Authentication design reflects operational maturity. Weak controls signal weak governance.
The Bigger Lesson: Authentication Is About Outcomes
Authentication should establish the required assurance for authorized access.
It is about preventing account compromise in the real world, under real conditions, with real humans.
Security-By-Design rejects simplistic answers. It builds layered systems that acknowledge trade-offs, handle failure gracefully, and align protection with risk.
Contextual Authentication Requirements
Select authentication according to the action, threat model and recovery requirements.
The method should fit the documented assurance requirement.
Authentication, sessions and recovery form a layered account-protection design. Each method needs a documented purpose and tested failure handling.
Security controls should have a clear purpose and understandable interaction.
Its purpose is to limit unauthorized access and support an accountable response to compromise.
This is how we Become Alpha.