The Authentication Crisis in Crypto

Most credential-based breaches at crypto firms do not exploit zero-day vulnerabilities in exchange infrastructure or smart contract logic. They exploit the gap between the authentication methods that security teams believe are protecting their systems and the authentication methods that are actually in place for every user, on every device, every day. That gap is wider than most firms acknowledge.

The 2022 LastPass breach illustrates the pattern precisely. The initial compromise was not a sophisticated infrastructure attack: it began with a senior DevOps engineer's home computer being infected with a keylogger through a vulnerable third-party media application. That keylogger captured the engineer's master password, which the attacker then used to access the engineer's vault and extract the decryption keys needed to penetrate LastPass's shared cloud environment. One of only four people with access to those keys had no hardware-enforced authentication on their personal device. The rest followed from that single failure point.

In crypto the consequences of an equivalent failure are more severe. LastPass involved the exfiltration of encrypted vault data and credential records. A crypto firm with equivalent authentication weaknesses faces a threat actor that can use the same credential access to initiate irreversible on-chain transactions. There is no fraud team to call and no reversal mechanism. The authentication failure and the asset loss are separated by seconds.

The pattern is consistent across the industry. Social engineering attacks targeting crypto firms consistently focus on credential theft as the primary initial access vector, precisely because most firms have not closed the authentication gap between their stated security standards and their actual controls. SMS one-time passwords (OTP) can be bypassed through SIM swapping. Time-based OTP (TOTP) codes can be relayed in real time by a proxy phishing page. Both of these bypass methods are well within the operational capability of the threat actors that target crypto firms.

Passkeys and hardware security keys solve these problems at the protocol level. They do not require users to type or transmit a secret that can be intercepted. They bind the authentication to the specific domain or service, making relay attacks structurally impossible. The question for a crypto security team is not whether to adopt these controls, but how to deploy them correctly across a tiered access model that reflects the differing risk levels of different operations.

The Evolution of Authentication: From Passwords to FIDO2

Understanding why passkeys and hardware security keys represent a genuine security advance, rather than incremental improvement, requires a clear view of what each preceding generation of authentication was attempting to solve and where it failed.

Passwords: The Original Problem

Passwords are a shared-secret authentication model. The user and the server each hold the same secret, and authentication succeeds when the user demonstrates knowledge of that secret. The structural weakness is in the sharing: a server that holds a database of passwords is a high-value target, and a password entered by a user on a phishing page is indistinguishable from one entered on the legitimate site. Both failures are endemic to the password model and cannot be patched away. They are properties of the architecture.

In crypto, passwords used alone are not a meaningful security control for anything beyond the most low-sensitivity access. Yet they remain the baseline authentication method for a significant proportion of access across the industry, frequently protected only by policies against reuse that are difficult to verify and easy to circumvent.

TOTP: A Partial Fix That Created New Vulnerabilities

Time-based one-time passwords, generated by authenticator applications such as Google Authenticator or Authy, were introduced to layer a second factor on top of passwords. The second factor is time-sensitive and single-use, which addresses some password replay attacks. But TOTP has two structural weaknesses that matter significantly in the crypto threat environment.

First, TOTP codes can be relayed in real time. A phishing page that captures a username, password, and TOTP code can immediately relay those credentials to the legitimate service before the code expires, giving the attacker an authenticated session. Real-time relay toolkits for this purpose are commercially available and require no sophisticated capability to operate. Nation-state actors targeting crypto employees use them routinely.

Second, the TOTP seed can be stolen. If an attacker compromises the device on which the authenticator application runs, or obtains the seed during enrolment, they can generate valid TOTP codes indefinitely. The LastPass breach involved the theft of credentials including MFA recovery codes from compromised vaults, giving the attacker the ability to bypass TOTP protections entirely.

FIDO2 and WebAuthn: Cryptographic Authentication

The FIDO2 standard and its browser-level implementation WebAuthn represent a fundamental architectural shift. Rather than transmitting a shared secret or a time-sensitive code, FIDO2 uses public-key cryptography to create an authentication ceremony that cannot be intercepted or relayed.

During registration, the authenticator generates a unique key pair for the specific service. The private key is stored securely on or in the authenticator and never transmitted. The public key is registered with the service. During authentication, the service issues a cryptographic challenge that the authenticator signs with the private key. The service verifies the signature against the registered public key. Because the private key never leaves the authenticator, there is nothing to steal from the network. Because the key pair is bound to the specific service's origin (its domain), a phishing page that does not share that exact domain cannot trigger a valid authentication signature. The relay attack that defeats TOTP is architecturally impossible against FIDO2.

Passkeys and hardware security keys are both implementations of FIDO2. The distinction between them lies in where the private key is stored and what protections surround it.

Passkeys Explained: How They Work and What They Protect Against

A passkey is a FIDO2 credential stored on a device using the platform's built-in secure storage, typically a Trusted Platform Module (TPM) on Windows devices, a Secure Enclave on Apple devices, or equivalent protected storage on Android. Authentication is confirmed by the user via biometric (Face ID, fingerprint, Windows Hello) or device PIN, and the authentication event generates a cryptographic signature that is sent to the service without transmitting the underlying private key.

Device-Bound Passkeys

A device-bound passkey exists only on the specific device on which it was created. The private key cannot be exported and does not leave the device. If the device is lost, the passkey associated with that device is inaccessible, and the user must re-enrol using a backup method. Device-bound passkeys meet NIST Authenticator Assurance Level 3 (AAL3) requirements when the device's secure storage is hardware-backed and the private key is non-exportable. They provide strong assurance that the credential is tied to a specific piece of hardware in the user's possession.

Synced Passkeys

Synced passkeys are credentials that are replicated across a user's devices through a cloud keychain service, such as Apple's iCloud Keychain or Google Password Manager. The credential is generated on one device and then synchronised to other devices enrolled in the same cloud account. Synced passkeys retain the phishing resistance of FIDO2 because the origin-binding and the challenge-response cryptography function identically to device-bound passkeys. However, they introduce a dependency on the security of the cloud account: if an attacker compromises the user's iCloud or Google account, they may be able to access the synced passkey.

For crypto teams, this distinction is material. A synced passkey stored in a personal iCloud account is only as secure as that Apple ID, which may have weaker recovery options and be accessible from personal devices with lower security baselines than corporate equipment. The correct approach for corporate use is to ensure passkeys are enrolled in managed, corporate-controlled credential stores, not personal cloud accounts.

What Passkeys Protect Against

Passkeys eliminate the primary attack vectors that defeat passwords and TOTP. They cannot be phished: the authentication signature is bound to the legitimate service's domain and a phishing page cannot trigger a valid signature. They cannot be guessed: there is no shared secret with dictionary attack surface. They cannot be reused across services: each key pair is unique to the service for which it was created. They are resistant to server-side database breaches: even if the service's public key database is exfiltrated, the private keys remain on user devices and cannot be derived from public key material. Real-time relay attacks that defeat TOTP are blocked by the origin-binding at the protocol level.

Where Passkeys Have Limits in the Crypto Context

Passkeys are an authentication mechanism. They govern who can access an application or service. They do not protect the private keys that control crypto assets: that is the domain of hardware security modules and hardware wallets. A passkey secures the login to a wallet management dashboard; it does not secure the wallet's signing key itself. For crypto-specific operations involving direct private key management, passkeys are a necessary but not sufficient control.

Additionally, synced passkeys introduce cloud account dependency that is unacceptable for the most sensitive access tiers. For privileged access, system administration, and any account that controls crypto asset infrastructure, the appropriate control is a hardware security key, not a synced passkey stored in a cloud account that could be subject to social engineering recovery attacks.

Hardware Security Keys: Dedicated Physical Authentication

A hardware security key is a dedicated physical device, separate from any general-purpose computer or smartphone, that stores FIDO2 credentials in tamper-resistant hardware and requires physical interaction to authenticate. The YubiKey range from Yubico is the most widely deployed, but the category includes Google's Titan Security Key and OnlyKey, among others. All implement the FIDO2/WebAuthn standard and provide the same phishing-resistant authentication as passkeys, with additional security properties that arise from the dedicated hardware design.

How Hardware Security Keys Differ from Passkeys

The central distinction is the hardware boundary. In a passkey, the private key is stored in the secure enclave or TPM of a general-purpose device that also runs an operating system, applications, and network connections. The secure enclave is well-designed and resistant to most attacks, but the device as a whole is a large attack surface. Malware running on the device could potentially attempt to abuse the credential-use capability even if it cannot extract the raw key material.

A hardware security key's private key is stored in a dedicated, single-purpose secure element. The device has no operating system, no application layer, and no network interface. It cannot be compromised by malware on the host computer because there is nothing on it for malware to execute. The private key cannot be backed up, cloned, or exported: this is by design. The physical possession requirement is absolute. An attacker without the physical device cannot authenticate, regardless of what credentials they have obtained by other means.

Hardware security keys also implement touch confirmation: the user must physically tap the key to authorise an authentication event. This prevents remote attacks that attempt to trigger authentication silently in the background, a category of attack that is theoretically possible against software-based authenticators on a compromised device.

YubiKey in Depth

The YubiKey 5 series supports FIDO2/WebAuthn, FIDO U2F, PIV smart card, OpenPGP, and OATH-TOTP across a single device. For most crypto team deployments, FIDO2 is the relevant protocol. YubiKeys do not require batteries, have no display or cellular connectivity, and are rated to survive physical abuse (waterproof, crushproof). They connect via USB-A, USB-C, or NFC depending on the model, which matters for laptop and mobile device compatibility planning.

The attestation capability of YubiKeys is valuable in enterprise deployments: the FIDO2 attestation certificate allows an identity provider to verify that a specific credential was created on a genuine YubiKey with a specific firmware version, rather than a software authenticator claiming to be a hardware key. For crypto firms building out identity governance that must satisfy regulatory scrutiny, this attestation provides a verifiable audit record of which physical devices are enrolled as authenticators.

Device-Bound vs Hardware: The NIST Assurance Level Distinction

NIST Special Publication 800-63B defines three Authenticator Assurance Levels (AAL). AAL2 requires multi-factor authentication with at least one phishing-resistant option; FIDO2 passkeys, both synced and device-bound, satisfy AAL2. AAL3 requires multi-factor authentication with hardware-based, non-exportable private keys: synced passkeys are explicitly excluded at AAL3 because the cloud synchronisation introduces exportability risk. Device-bound passkeys on a hardware security key meet AAL3. This distinction matters when a regulatory framework requires the highest assurance level for privileged or sensitive operations.

The Crypto Threat Model: Why Standard MFA Fails

The threat actors that target crypto firms operate at a sophistication level that renders standard MFA controls ineffective. Understanding the specific techniques in use is necessary to appreciate why phishing-resistant authentication is a structural requirement rather than a nice-to-have upgrade.

Lazarus Group and State-Sponsored Credential Harvesting

The Lazarus Group, operating under North Korea's Reconnaissance General Bureau, is the most consequential threat actor targeting the crypto industry. In 2025 alone, North Korean state-sponsored hackers stole in excess of $2 billion in cryptocurrency across multiple campaigns. The group's TraderTraitor suboperation has been directly attributed by the FBI and Japan's National Police Agency to major exchange heists including the $308 million DMM Bitcoin theft in May 2024 and the $1.5 billion Bybit breach in early 2025.

The Lazarus Group's operational approach against crypto employees is extensively documented. In the DMM Bitcoin breach, attackers posed as recruiters on LinkedIn to lure a developer at Ginco into running a malicious Python script disguised as a coding challenge on GitHub. The script harvested SSH keys, saved credentials, and cloud configuration files. The stolen session cookies were then used to access Ginco's internal systems and ultimately redirect a legitimate Bitcoin transfer. TOTP-based MFA did not prevent this attack because the credential harvest was not phishing a login page: it was harvesting cached session material from a compromised device.

For a detailed analysis of Lazarus Group's credential harvesting techniques and the operational security measures required to defend against them, the threat picture extends well beyond authentication controls alone. But authentication is the layer at which the initial access vector can be most directly countered.

SIM Swapping and SMS OTP Bypass

SIM swapping, the fraudulent transfer of a victim's mobile number to an attacker-controlled SIM card, is a technique that fully bypasses SMS OTP. It requires social engineering of a mobile network operator, a capability that is trivial for organised criminal groups and entirely within the operational reach of state-sponsored actors. Once the SIM swap is complete, the attacker receives all SMS messages to the victim's number, including OTP codes for any service using SMS-based MFA.

SMS OTP was already a deprecated authentication control in high-security environments before it became a known weakness in the crypto threat context. Several high-profile crypto industry figures have had accounts compromised through SIM swapping despite using other security practices. NIST explicitly removed SMS OTP from its list of recommended authenticators in the draft SP 800-63-4. Firms still relying on SMS OTP for any access tier in their authentication stack have a known, documented, and actively exploited vulnerability that should be treated as an open risk item requiring immediate remediation.

Real-Time Phishing Proxy Attacks on TOTP

Real-time phishing proxy attacks use an intermediary server that sits between the victim and the legitimate service. When the victim enters their username, password, and TOTP code on the phishing page, the proxy immediately relays those credentials to the real service and establishes an authenticated session. The TOTP code is valid for 30 seconds, which is sufficient for the relay. The attacker receives a valid session token without ever needing to know the TOTP seed.

Toolkits for executing this attack, such as Modlishka and Evilginx2, are publicly available and require minimal technical capability to deploy. They are actively used against crypto industry targets. Phishing-resistant authentication methods like FIDO2 passkeys and hardware security keys are immune to this attack because the authentication signature is bound to the domain of the legitimate service. Even if a user visits a convincing proxy phishing page, the authenticator will not produce a valid signature for the fraudulent origin, and the authentication will fail before the user's credential is transmitted.

The Specific Threat to Crypto Employee Devices

Crypto employees are disproportionately targeted by campaigns designed to compromise their devices rather than intercept their credentials in transit. The Lazarus Group's "Operation Dream Job" and its successor "ClickFake Interview" campaign use fake job offers and coding challenges to deliver malware, including the GolangGhost backdoor and credential-harvesting tools, to developer and DevOps targets at crypto firms. These attacks deliver malware that can harvest session cookies, SSH keys, and cloud credentials from the compromised device.

Hardware security keys provide a meaningful defence against device-compromise attacks because the FIDO2 private key cannot be extracted from the secure element even by malware with full operating system access. An attacker who has achieved code execution on an employee's laptop cannot silently authenticate as that user to FIDO2-protected services without also physically possessing the hardware key. The touch confirmation requirement adds a further barrier: any attempt to trigger authentication in the background requires a physical human interaction that a remote attacker cannot perform.

Decision Framework: Which Authentication Method for Which Use Case

A sound authentication architecture for a crypto firm is not a single uniform policy applied across all users and systems. It is a tiered model that matches the authentication assurance level to the risk level of the operation being protected. The following framework provides a practical basis for making those decisions.

Tier 1: Standard Employee Application Access

For access to standard business applications, collaboration tools, email, and low-sensitivity internal systems, passkeys represent a significant and proportionate security upgrade over passwords and TOTP. Device-bound passkeys on managed corporate devices, enrolled through a corporate identity provider such as Okta or Microsoft Entra ID, provide phishing-resistant MFA that eliminates the relay attack vectors described above while remaining user-friendly enough to achieve broad adoption without friction.

The key governance requirement at this tier is ensuring that passkeys are enrolled in corporate-managed credential stores rather than personal cloud accounts, and that the corporate identity provider enforces passkey authentication rather than allowing fallback to password-plus-TOTP.

Tier 2: Admin, Privileged, and Infrastructure Access

Access to cloud infrastructure management, system administration consoles, CI/CD pipelines, code signing, and deployment tooling requires hardware FIDO2 security keys as the mandatory authentication method. These are the access paths that, if compromised, allow an attacker to modify production code, alter infrastructure configuration, or access secret stores. They represent the highest-consequence access category in the technology stack, and the authentication assurance level must match.

Hardware security keys should be mandatory for all privileged users, as defined in the organisation's privileged access management policy. The identity provider should enforce attestation verification to confirm that the authenticator is a genuine hardware device, not a software passkey. Synced passkeys should be explicitly blocked for this access tier.

Tier 3: DAO Governance, Multisig, and Protocol Admin

On-chain governance operations, multisig transaction signing, and smart contract admin role operations sit at the apex of the risk model. These are operations where a single compromised action can result in irreversible asset loss or permanent protocol compromise. Hardware security keys are mandatory for the authentication layer controlling access to the interfaces through which these operations are initiated. No synced passkey, software TOTP, or SMS OTP is an acceptable authentication method for any account with signing authority over protocol funds or governance votes.

The principle extends to the workstations used for these operations. Governance signing should be performed from dedicated, hardened devices that are not used for general browsing, email, or software installation. Identity and access management controls for governance roles must include not just authentication strength but device health attestation and network access controls.

Tier 4: Private Key Operations and Signing

Private key operations, including key generation, custody signing, and key rotation, are not authentication operations in the FIDO2 sense. They require hardware security modules for key operations rather than authentication tokens. An HSM provides a dedicated cryptographic execution environment where private key material is generated and used without ever being exposed to host operating system memory. This is categorically different from, and complementary to, authentication controls.

The relationship between the two is straightforward: hardware security keys protect the authentication to the systems that manage HSMs. HSMs protect the cryptographic key material itself. Both controls are necessary; neither is a substitute for the other.

Summary Decision Table

Use Case	Minimum Requirement	Preferred Control
Standard employee application access	Passkey (device-bound, corporate-managed)	Hardware FIDO2 key
Admin and privileged access	Hardware FIDO2 key	Hardware FIDO2 key with attestation verification
Code signing and CI/CD pipelines	Hardware FIDO2 key	Hardware FIDO2 key with device health attestation
DAO governance and multisig signing	Hardware FIDO2 key	Hardware FIDO2 key on dedicated signing workstation
Private key generation and custody signing	HSM	HSM with hardware FIDO2 key for admin access
Remote worker general access	Passkey (device-bound, corporate-managed)	Hardware FIDO2 key issued and enrolled before remote deployment

Implementation Guide: Rolling Out Passkeys and Hardware Keys

A well-designed authentication rollout follows a structured sequence: policy, procurement, enrolment, enforcement, and ongoing management. Each step has specific considerations for crypto teams that differ from a standard enterprise deployment.

Step 1: Define Your Authentication Policy

Before purchasing any hardware, document the authentication policy that the rollout will implement. The policy should define: which access tiers map to which authentication requirements; which identity provider will enforce authentication; what fallback authentication methods are permitted (and for which tiers no fallback is acceptable); what the enrolment deadline is; and what happens when a hardware key is lost or a device is replaced. Without a written policy, a hardware key rollout becomes a collection of enrolled credentials with no consistent enforcement behind it.

The policy should explicitly prohibit SMS OTP and software TOTP as authentication methods for Tier 2 and above. It should specify that passkeys enrolled in personal cloud accounts (personal iCloud, personal Google account) are not acceptable for corporate authentication. Both of these prohibitions will require active enforcement in the identity provider configuration: users will choose the path of least resistance unless the policy is enforced at the technical level.

Step 2: Select and Procure Hardware

For most crypto team deployments, the YubiKey 5 series is the appropriate choice. Select the connector type that matches the primary devices used by your team: USB-C for modern laptops, USB-A for older equipment, and ensure NFC capability for any authentication scenarios involving mobile devices. Issue a minimum of two hardware keys per user: one primary and one backup. The backup key should be enrolled on all the same services as the primary and stored securely off-site or in a secure location accessible to the firm in the event of loss.

Bulk procurement directly from Yubico or an authorised distributor provides supply chain assurance that keys are genuine and have not been intercepted and modified. Verify the authenticity of YubiKey hardware using Yubico's YubiKey Verification Service before enrolment. For Titan keys, similar verification is available from Google.

Step 3: Configure Your Identity Provider

The identity provider, whether Okta, Microsoft Entra ID, Google Workspace, or an equivalent, is where authentication policy is enforced at scale. Configure the identity provider to: require FIDO2 as the authentication method for all corporate applications; enforce hardware key attestation for Tier 2 and above access; block legacy authentication protocols (Basic Auth, NTLM) that bypass MFA entirely; and prevent fallback to password-plus-TOTP for enrolled users who have completed hardware key enrolment. Test each configuration change against a pilot group before organisation-wide rollout.

Step 4: Enrolment Programme

Enrolment should be conducted in a structured, assisted manner rather than left to users to complete independently. For hardware keys, a managed enrolment session ensures that both primary and backup keys are registered, that the user understands the physical requirements (key must be present, touch confirmation is required), and that the backup key is stored in the designated secure location rather than carried alongside the primary. Document the enrolment event: which serial-numbered keys were issued to which user, on which date, for which services.

For passkey rollouts on corporate devices, ensure that passkeys are created using the corporate-managed platform credential store rather than a personal browser or cloud account. In Microsoft environments, this means Windows Hello for Business enrolled through Intune. In Apple environments, it means passkeys created within the corporate Apple Business Manager identity context, not a personal Apple ID.

Step 5: Lost Key Procedure

The most common operational objection to hardware security keys is the question of what happens when a key is lost. The answer must be defined in the policy and tested before the rollout is complete, not improvised when the first loss occurs.

The procedure should follow this sequence: the user reports the lost key to the security team immediately; the lost key's credential is revoked on all enrolled services using the serial number recorded at enrolment; the user authenticates to the identity provider using their backup key; a replacement primary key is procured and enrolled; the backup key is reinstated to its backup location once the replacement is in service. The critical point is that revocation of the lost key must happen before the user is given any other authentication path, including a temporary fallback to password-plus-TOTP, which would negate the security benefit of the hardware key policy for the duration of the fallback period.

Step 6: Remote Worker Considerations

Remote crypto teams introduce logistics challenges for hardware key rollouts that must be addressed in the implementation plan. Hardware keys for remote workers should be procured and enrolled centrally, with enrolment completed on at least one service before the key is shipped. This ensures the key has been tested and is associated with the correct user identity before it leaves a controlled environment. For fully distributed teams where in-person enrolment is not possible, a remote enrolment procedure should be designed and tested, using a video-verified identity confirmation step before keys are activated.

Remote workers are also more likely to be targeted by the social engineering campaigns that the Lazarus Group and similar actors use as initial access vectors: fake job interviews, phishing lures designed to look like internal IT communications, and malware delivered through developer tooling. Hardware key authentication limits the blast radius of a successful device compromise, but it does not prevent initial access through non-authentication vectors. Authentication controls for remote teams must be complemented by endpoint detection, secure communication practices, and security awareness training.

Regulatory Requirements: DORA and MiCA

The regulatory environment for crypto-asset service providers in the European Union has clarified significantly since MiCA came into force and DORA became applicable to financial entities in January 2025. Both frameworks create obligations that, while they do not mandate specific authentication technologies by name, establish performance requirements that practically require phishing-resistant MFA.

DORA's Strong Authentication Requirements

DORA Article 9 requires financial entities to implement "strong authentication mechanisms" as part of their ICT security policies. The DORA Regulatory Technical Standards specify that strong authentication must use at least two independent authentication factors and must be resistant to credential-based attacks. For privileged users and administrators, the requirement for phishing-resistant MFA is explicit in the guidance issued by EBA and ESMA: FIDO2/WebAuthn is identified as the current standard for satisfying this requirement.

DORA also requires documented ICT risk management controls, periodic testing of those controls, and evidence that authentication policies are enforced consistently rather than only on paper. An audit that finds a documented hardware key policy but unmanaged fallback authentication in practice will identify this as a control deficiency. The enforcement of authentication policy must be verifiable through identity provider logs and configuration attestation.

MiCA Operational Security Requirements for CASPs

MiCA requires crypto-asset service providers to implement security access protocols covering authentication, authorisation, and access rights management for all systems that support the provision of crypto-asset services. Access to systems handling client assets, order management, or key management infrastructure must be subject to defined controls, with documented evidence of who has access, at what privilege level, and under what approval process.

For CASPs, the combination of MiCA operational security requirements and DORA ICT risk management obligations creates a regulatory expectation that is difficult to satisfy with password-plus-TOTP authentication on privileged accounts. Hardware security keys for admin and privileged access, with device-bound passkeys for standard access, constitutes a defensible authentication architecture under both frameworks. A tiered authentication policy that can be demonstrated in an audit, with identity provider configuration screenshots and enrolment records as evidence, satisfies the documented control requirement.

GDPR and Authentication Record Keeping

Authentication events constitute access control logs that have relevance under GDPR Article 32, which requires technical measures appropriate to the risk of processing personal data. Authentication logs must be retained for a period sufficient to support incident investigation. For crypto firms that hold personal data on clients (which all MiCA-registered CASPs will), the authentication log retention and access control review obligations compound the requirement for a structured, auditable authentication architecture.

Common Mistakes That Negate the Security Benefit

A significant proportion of authentication security failures in crypto firms occur not because the firm failed to deploy better controls, but because the controls were deployed incompletely, inconsistently, or with exceptions that created the same vulnerabilities the deployment was intended to close.

Allowing SMS OTP as a Fallback

The most common and consequential authentication policy mistake is permitting SMS OTP as a fallback for users who cannot complete hardware key or passkey authentication. A fallback authentication method is only as secure as the weakest method permitted. If an attacker can trigger the fallback to SMS OTP by claiming the primary authenticator is unavailable, the entire FIDO2 investment provides no protection against an attacker who has the victim's phone number and can execute a SIM swap. The fallback must be either a backup hardware key or an account recovery procedure that involves identity verification through a channel separate from the phone number.

Not Enforcing Hardware Keys for Admin Accounts

Many firms roll out hardware keys for standard users but fail to enforce them for administrator and privileged accounts, treating admin users as exceptions because enforcing the policy creates friction with senior technical staff. This is the highest-risk exception possible. Admin and privileged accounts are precisely the accounts that threat actors prioritise in targeted attacks, because compromising a standard user account provides limited access while compromising an admin account provides infrastructure-level access. If hardware key enforcement is applied anywhere in the organisation, it must be applied first and most strictly to privileged accounts.

Failing to Enrol Backup Keys

Issuing a single hardware key per user without a backup creates an operational fragility that leads to security compromises. When a key is lost and no backup exists, the natural response is to create a temporary authentication path, typically password-plus-TOTP, to allow the user to continue working while a replacement is procured. That temporary path creates the vulnerability window that the hardware key was installed to prevent. A backup key, enrolled during the initial enrolment session and stored securely, eliminates the need for any fallback.

Mixing Personal and Corporate Passkeys

When passkey enrolment is left to users to complete without explicit guidance, it is common for passkeys to be created in the user's personal iCloud Keychain or Google Password Manager rather than in a corporate-managed credential store. A passkey in a personal cloud account is accessible from any device the user logs into with their personal credentials, including personal devices with no corporate security controls and potentially shared family devices. The passkey may also be recoverable by anyone who can access the user's personal cloud account recovery process. Corporate passkeys must be enrolled in corporate-managed stores, and the identity provider should be configured to verify passkey origin and reject credentials created on personal credential managers for sensitive access tiers.

No Lost-Key Escalation Procedure

Without a documented and tested lost-key procedure, a lost hardware key becomes an improvised incident with no defined resolution path. The result is typically an ad hoc exception to the authentication policy, granted under time pressure, which creates a precedent and a vulnerability. Define the procedure before the first key is issued, communicate it to all users as part of the enrolment programme, and test it with a simulated loss event before the rollout is complete.

Permitting Legacy Authentication Protocols

Modern identity providers can enforce FIDO2 authentication at the identity layer, but legacy authentication protocols, including Basic Auth, NTLM, and legacy SMTP authentication, bypass the identity provider entirely. If any application in the environment accepts these protocols, an attacker who obtains a password hash or cleartext credential can authenticate directly without triggering MFA. Legacy protocol blocking must be enforced at the identity provider and verified through authentication log analysis before the hardware key rollout can be considered complete.

People, Process, Technology: Authentication as a System

Authentication technology, whether passkeys or hardware security keys, does not function as a security control in isolation. It functions as part of a system that includes the people using it and the processes governing its deployment, maintenance, and enforcement. A hardware key rollout that treats the technology as the complete solution, rather than one component of a three-part system, will produce an incomplete result.

Technology: The Necessary Foundation

The technology layer is the foundation: FIDO2-capable hardware keys, a compatible identity provider, applications that support WebAuthn, and device management that can enforce authentication policy. Without the right technology choices, the other components have nothing to work with. But technology alone is insufficient. A correctly configured identity provider will enforce the authentication policy it has been given. If that policy contains exceptions, the exceptions create vulnerabilities. If the policy is not applied consistently to all users and all access paths, the uncovered paths become the attack surface.

Process: Making Technology Enforceable

Process is what makes the technology enforceable at scale over time. The authentication policy, the enrolment programme, the lost-key procedure, the onboarding and offboarding integration, the periodic access review, and the exception approval process are all process components that determine whether the technology is consistently applied. A CISO who deploys hardware keys without updating the onboarding process will find new joiners authenticating with passwords while waiting for their keys to arrive. A security team that does not integrate hardware key revocation into offboarding will have former employees with registered authenticators on departed accounts.

Process integration means that authentication controls are embedded in every relevant workflow: new hire provisioning, role change, contractor engagement, departure, account recovery, device replacement, and periodic access review. Each of these touchpoints is an opportunity for the authentication policy to be correctly applied or incorrectly bypassed.

People: Training, Compliance, and Culture

The people component covers two dimensions: user competence and user compliance. Competence means that every user understands how to use their passkey or hardware key correctly, what to do when authentication fails, how to report a lost key, and why the controls exist. Security awareness training that explains the phishing relay attack in concrete terms, rather than abstract policy language, gives users a mental model for why touching a key is required rather than just clicking an on-screen button.

Compliance means that the authentication policy is applied consistently and that exceptions are genuinely exceptional. Security culture in crypto firms frequently grants wide latitude to senior technical staff who find security controls inconvenient. The threat actors that target crypto firms are aware of this pattern and specifically target senior technical personnel precisely because they are likely to have received MFA exceptions or to have elevated privileges. The argument that enforcing hardware keys on a senior engineer creates friction is true; the counter-argument is that a senior engineer with admin access and weak authentication is the highest-value target in the organisation. Security culture must frame strong authentication as a professional norm, not an imposition.

"Authentication technology that is deployed but not enforced is not a security control: it is a performance of security that provides no actual protection. The gap between having hardware keys issued and having hardware keys enforced for every access path is exactly the gap that threat actors exploit."

Security4Web3 works with crypto firms and Web3 protocols to design and implement authentication architectures that function as complete systems. Our team brings experience from the defence industry, where the consequence of an authentication failure on a privileged account is treated with the same seriousness it deserves in crypto, combined with deep operational knowledge of the specific access models and tooling stacks that crypto teams use. If your firm is operating with TOTP or SMS OTP on any access tier that controls crypto assets, that is an open risk item that warrants a structured remediation plan.

Frequently Asked Questions

What are passkeys and how do they differ from passwords?

Passkeys are cryptographic credentials stored on a device using public-key cryptography. Unlike passwords, they cannot be phished, guessed, or reused across sites. The private key never leaves the device, and authentication is confirmed via biometric or device PIN.

Are passkeys secure enough for crypto organisations?

Passkeys offer strong phishing resistance and are suitable for most internal systems and application access. For signing high-value crypto transactions or managing private keys, hardware security keys (FIDO2) or HSMs remain the gold standard due to their physical tamper resistance.

What is the difference between passkeys and hardware security keys?

Passkeys are stored on a user's device or in a cloud keychain and rely on device security. Hardware security keys are dedicated physical devices (such as YubiKey) that store credentials in tamper-resistant hardware, providing stronger isolation for critical operations.

Which authentication method should crypto teams use?

The answer depends on the sensitivity of the operation. Passkeys are appropriate for standard application access. Hardware security keys should be used for privileged access, admin accounts, and any system that controls crypto assets. HSMs are required for private key operations.

How should crypto firms manage authentication for remote teams?

Remote crypto teams should implement a tiered authentication policy: passkeys or TOTP for low-sensitivity systems, hardware FIDO2 keys for privileged and administrative access, and HSMs for all key management operations. This tiering ensures security controls are proportionate to the risk.

Does DORA require strong authentication for crypto-asset service providers?

DORA mandates that financial entities implement strong authentication controls as part of their ICT risk management framework. For crypto-asset service providers under MiCA, implementing phishing-resistant authentication such as FIDO2 passkeys or hardware security keys is a practical requirement for demonstrating compliance.