Practical Tips and Recommendations for WebAuthn Implementation

Implementing WebAuthn, whether for SSH access or web applications, requires attention to detail. These practical tips and examples will help you avoid common pitfalls and ensure reliable system operation.

1. Implementing WebAuthn for SSH/PAM on Linux

To secure SSH access on Linux, we will use pam_u2f — a PAM module that allows the use of FIDO2-compatible authenticators (including Passkeys, if they function as CTAP2 devices) for system authentication. In 2026, this module is a mature solution.

Step 1: Install necessary packages

Ensure that libfido2 and pam_u2f are installed. Depending on your Linux distribution, commands may vary.

# For Debian/Ubuntu (current for 2026)
sudo apt update
sudo apt install libfido2-dev libpam-u2f -y

# For RHEL/CentOS/Fedora
sudo dnf install libfido2-devel pam_u2f -y
    

Step 2: Register your FIDO2 key (Passkey)

Each user must register their FIDO2 key. This process creates a unique mapping file between the Linux user and the key identifier. Use the pamu2fcfg utility.

# As the user who will use the key
pamu2fcfg -u $(whoami) > ~/.config/Yubico/u2f_keys

# Example content of ~/.config/Yubico/u2f_keys:
# username:key_handle,public_key
# user1:AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCD...
    

Important: Make sure your FIDO2 key is connected when you execute this command. For Passkeys stored on a platform authenticator (e.g., a smartphone), the process might be more complex and require special software or USB device emulation.

For centralized key management in an enterprise environment, u2f_keys can be stored in a centralized directory (e.g., NFS, LDAP) and pam_u2f configured to use it.

Step 3: Configure PAM for SSH

Edit the PAM configuration file for SSH. This is usually /etc/pam.d/sshd.

sudo nano /etc/pam.d/sshd
    

Add the following line at the beginning of the file, before any other auth directives. This will provide two-factor authentication (password + key).

# Add to the very beginning
auth       required   pam_u2f.so cue [debug] authfile=/etc/Yubico/u2f_keys store_directory=/etc/Yubico

# If you want to allow using the key file in the user's home directory:
# auth       required   pam_u2f.so cue [debug]
    

Parameters:

• cue: Prompts the user to tap the key.
• debug: Useful for debugging.
• authfile=/etc/Yubico/u2f_keys: Points to a centralized key file (if used). If not specified, the module looks for ~/.config/Yubico/u2f_keys.
• store_directory=/etc/Yubico: Directory for storing metadata.

If you want completely passwordless login with a FIDO2 key, you will need a more complex PAM setup, possibly using sufficient instead of required, but this requires careful planning and backup methods.

Step 4: Configure the SSH daemon

Edit the SSH daemon configuration file /etc/ssh/sshd_config.

sudo nano /etc/ssh/sshd_config
    

Ensure that the following parameters are set:

ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
    

AuthenticationMethods specifies that the user can authenticate using a public key (if configured) OR using an interactive response (PAM, which now includes U2F/FIDO2). Restart the SSH daemon:

sudo systemctl restart sshd
    

Step 5: Testing

Open a new terminal session (do not close the current one until you are sure everything works!). Try connecting to the server via SSH. You will be prompted to enter your password, and then to tap your key.

ssh user@your_server_ip
    

If you are using Passkeys synchronized with your smartphone, you may need to confirm the login on your phone.

2. Implementing WebAuthn for web applications (using Python/Node.js as examples)

For web applications, the process involves both server-side and client-side components. We will cover the general logic.

Step 1: Choose a server-side library

Use a mature and well-supported library for your backend.

• Python: fido2 (from Yubico) or py_webauthn.
• Node.js: @simplewebauthn/server.
• Go: go-webauthn.
• PHP: web-authn/web-authn.

Step 2: Configure RP ID and Origin

These are critically important parameters. rpId (Relying Party ID) is the domain that is the source of the authentication request. origin is the full URL, including scheme and port. They must match exactly. For rpId, the domain is usually used (e.g., example.com).

// Node.js (example)
const rpId = 'your-domain.com'; // Use the root domain without subdomains if Passkeys should work on all subdomains.
const origin = https://${rpId}; // Full URL with HTTPS.
    

Step 3: Implement Registration (Enrollment)

The registration process consists of two stages: requesting registration options and completing registration.

Server-side (Node.js with @simplewebauthn/server):

// 1. /api/generate-registration-options
import { generateRegistrationOptions } from '@simplewebauthn/server';
import { origin, rpId } from './config'; // Your RP ID and Origin

app.post('/api/generate-registration-options', async (req, res) => {
    const { userId, userName } = req.body; // Get user ID and name

    const options = await generateRegistrationOptions({
        rpName: 'My Secure App', // Your company/application name
        rpId: rpId,
        userID: userId,
        userName: userName,
        attestationType: 'none', // Sufficient for most cases
        authenticatorSelection: {
            authenticatorAttachment: 'cross-platform', // 'platform' for built-in, 'cross-platform' for external (YubiKey)
            userVerification: 'preferred', // Prefer biometrics/PIN
        },
        timeout: 60000, // 60 seconds
        // Additional options, e.g., excludeCredentials to prevent registering one key multiple times
        excludeCredentials: await getExistingCredentialsForUser(userId),
    });

    // Save the challenge on the server, tied to the user's session, for subsequent validation
    req.session.currentChallenge = options.challenge;
    res.json(options);
});

// 2. /api/verify-registration
import { verifyRegistrationResponse } from '@simplewebauthn/server';

app.post('/api/verify-registration', async (req, res) => {
    const { registrationResponse } = req.body; // Response from the client

    try {
        const verification = await verifyRegistrationResponse({
            response: registrationResponse,
            expectedChallenge: req.session.currentChallenge, // Use challenge from session
            expectedOrigin: origin,
            expectedRPID: rpId,
            requireUserVerification: true, // Require user verification (PIN/biometrics)
        });

        const { verified, registrationInfo } = verification;
        if (verified && registrationInfo) {
            const { credentialID, credentialPublicKey, counter } = registrationInfo;
            // Save credentialID, credentialPublicKey, counter in your database, tied to userId
            // credentialPublicKey should be saved in COSE_KEY format (Buffer)
            // counter - for protection against replay attacks
            await saveCredentialToDatabase(userId, credentialID, credentialPublicKey, counter);
            res.json({ success: true, msg: 'Passkey successfully registered!' });
        } else {
            res.status(400).json({ success: false, msg: 'Passkey registration error.' });
        }
    } catch (error) {
        console.error('Registration verification error:', error);
        res.status(400).json({ success: false, msg: error.message });
    }
});
    

Client-side (JavaScript with @simplewebauthn/browser):

import { startRegistration } from '@simplewebauthn/browser';

async function registerPasskey(userId, userName) {
    try {
        // 1. Request registration options from the server
        const resp = await fetch('/api/generate-registration-options', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ userId, userName }),
        });
        const options = await resp.json();

        // 2. Start the registration process in the browser
        const attResp = await startRegistration(options);

        // 3. Send the browser's response to the server for verification
        const verificationResp = await fetch('/api/verify-registration', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ registrationResponse: attResp }),
        });
        const verificationResult = await verificationResp.json();

        if (verificationResult.success) {
            alert('Passkey successfully registered!');
        } else {
            alert('Registration error: ' + verificationResult.msg);
        }
    } catch (error) {
        console.error('Error during registration process:', error);
        alert('An error occurred while registering the Passkey.');
    }
}
    

Step 4: Implement Authentication

The authentication process also consists of two stages: requesting authentication options and completing authentication.

Server-side (Node.js with @simplewebauthn/server):

// 1. /api/generate-authentication-options
import { generateAuthenticationOptions } from '@simplewebauthn/server';

app.post('/api/generate-authentication-options', async (req, res) => {
    const { userName } = req.body; // Or userId, if you know it

    // Get a list of credentialIDs registered for this user
    const userCredentials = await getCredentialsByUserName(userName);

    const options = await generateAuthenticationOptions({
        rpId: rpId,
        // Allow the browser to suggest only the Passkeys we know
        allowCredentials: userCredentials.map(cred => ({
            id: cred.credentialID,
            type: 'public-key',
            transports: ['usb', 'nfc', 'ble', 'internal'], // Specify possible transports
        })),
        userVerification: 'preferred',
        timeout: 60000,
    });

    // Save the challenge on the server, tied to the user's session
    req.session.currentChallenge = options.challenge;
    res.json(options);
});

// 2. /api/verify-authentication
import { verifyAuthenticationResponse } from '@simplewebauthn/server';

app.post('/api/verify-authentication', async (req, res) => {
    const { authenticationResponse } = req.body;

    // Get Passkey data from the DB by credentialID, which came in authenticationResponse
    const credential = await getCredentialById(authenticationResponse.id);
    if (!credential) {
        return res.status(400).json({ success: false, msg: 'Key not found.' });
    }

    try {
        const verification = await verifyAuthenticationResponse({
            response: authenticationResponse,
            expectedChallenge: req.session.currentChallenge,
            expectedOrigin: origin,
            expectedRPID: rpId,
            authenticator: {
                credentialID: credential.credentialID,
                credentialPublicKey: credential.credentialPublicKey,
                counter: credential.counter, // For counter verification
            },
            requireUserVerification: true,
        });

        const { verified, authenticationInfo } = verification;
        if (verified) {
            // Update the counter in the DB for this credentialID
            await updateCredentialCounter(credential.credentialID, authenticationInfo.newCounter);
            // Authentication successful, set user session
            req.session.userId = credential.userId;
            res.json({ success: true, msg: 'Login successful!' });
        } else {
            res.status(400).json({ success: false, msg: 'Authentication error.' });
        }
    } catch (error) {
        console.error('Authentication verification error:', error);
        res.status(400).json({ success: false, msg: error.message });
    }
});
    

Client-side (JavaScript with @simplewebauthn/browser):

import { startAuthentication } from '@simplewebauthn/browser';

async function authenticateWithPasskey(userName) {
    try {
        // 1. Request authentication options from the server
        const resp = await fetch('/api/generate-authentication-options', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ userName }),
        });
        const options = await resp.json();

        // 2. Start the authentication process in the browser
        const authResp = await startAuthentication(options);

        // 3. Send the browser's response to the server for verification
        const verificationResp = await fetch('/api/verify-authentication', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ authenticationResponse: authResp }),
        });
        const verificationResult = await verificationResp.json();

        if (verificationResult.success) {
            alert('Login successful!');
            window.location.href = '/dashboard'; // Redirect
        } else {
            alert('Login error: ' + verificationResult.msg);
        }
    } catch (error) {
        console.error('Error during authentication process:', error);
        alert('An error occurred while logging in with Passkey.');
    }
}
    

3. General recommendations for both approaches

• Backup Keys: Always encourage users to register multiple Passkeys or have a backup authentication method. This is critical for access recovery.
• Key Lifecycle: Develop procedures for revoking lost/compromised keys and replacing them.
• Logging: Thoroughly log all events related to registration and authentication. This will help with debugging and security auditing.
• User Education: Explain to users how Passkeys work, why they are more secure, and how to use them. This will reduce support requests.
• HTTPS Everywhere: WebAuthn strictly requires HTTPS. Ensure your website or API is only accessible over a secure connection.
• Testing: Conduct comprehensive testing on various devices, browsers, and authenticators.

These recommendations and code examples provide a solid foundation for getting started with WebAuthn. Remember that security is an ongoing process, and your implementation should be regularly reviewed and updated.

Common Mistakes When Implementing WebAuthn

Implementing a complex technology like WebAuthn comes with certain pitfalls. Based on experience from 2026, we have identified the most common mistakes made by developers and administrators and offer ways to prevent them.

1. Incorrect RP ID and Origin Configuration

Mistake: Using an incorrect rpId (Relying Party ID) or origin. For example, setting rpId to a full domain with a subdomain (app.example.com) instead of the root (example.com), or a protocol mismatch (HTTP instead of HTTPS).

Consequences: WebAuthn will not work. The browser will reject authentication/registration requests due to a mismatch. This is a fundamental error that compromises protocol security, as rpId is bound to the origin. If rpId is configured as app.example.com, then the Passkey will not work for sub.app.example.com, which can be unexpected behavior.

How to avoid:

• Always use the root domain for rpId if you want Passkeys to work across all subdomains. For example, for app.example.com and test.example.com, use example.com as the rpId.
• The origin must exactly match the current URL, including the scheme (https://) and port.
• Carefully read the documentation for your WebAuthn server library, as it may have its own nuances in handling these parameters.
• Use HTTPS only. WebAuthn is strictly forbidden for HTTP.

2. Missing or Inadequate Account Recovery Mechanisms

Mistake: Assuming users will never lose their Passkey or all their authenticators. Failing to provide a secure and clear way to recover access.

Consequences: User lockout, data loss, immense burden on support services, negative user experience, and potential abandonment of WebAuthn.

How to avoid:

• Multiple Passkeys: Encourage users to register multiple Passkeys on different devices (smartphone, laptop, hardware key) or to have multiple hardware keys.
• Backup Codes: Provide users with the option to generate one-time backup codes that can be stored in a safe place.
• Recovery Delay: Implement an account recovery procedure that includes a delay (e.g., 24-48 hours) before activating a new method, to give the user time to react if the recovery request was initiated by an attacker.
• Enhanced Verification: For recovery via support services, require multi-factor verification of the user's identity (e.g., answers to secret questions, video call confirmation, document identification).
• Gradual Transition: In the initial stages, retain traditional 2FA methods as backups until users become accustomed to Passkeys.

3. Incorrect Authenticator Response Validation on the Server

Mistake: Incomplete or incorrect validation of all fields returned by the authenticator (e.g., challenge, origin, rpId, signature, counter, userVerification).

Consequences: Vulnerabilities to replay attacks, authentication spoofing, security bypasses. This is one of the most serious mistakes, as it can completely compromise the authentication system.

How to avoid:

• Use Proven Libraries: Always rely on mature, well-tested WebAuthn server libraries that implement all necessary checks according to the FIDO2 specification.
• Verify challenge: Ensure that the challenge received in the authentication response matches the one you originally sent and stored in the user's session (and which is cryptographically random and single-use).
• Verify origin and rpId: They must exactly match your expected values.
• Verify signature: The signature must be valid and performed by the public key registered for this Passkey.
• Verify counter: Ensure that the counter value returned by the authenticator is greater than the previously stored value. This protects against replay attacks.
• Verify userVerification: If you require user verification (PIN/biometrics), ensure that the uv flag is set in the response.

4. Ignoring Passkey Lifecycle and Management

Mistake: Lack of mechanisms for viewing, revoking, or updating registered Passkeys for a user.

Consequences: Difficulties for users who want to delete an old key, or for administrators who need to revoke a compromised key. This can lead to "dead" keys that continue to grant access, or an inability to manage security.

How to avoid:

• Key Management Panel: Provide users in their profile with the ability to view their registered Passkeys, give them clear names, and delete them.
• Administrative Panel: Administrators should have the ability to forcibly revoke Passkeys for any user in the event of a security incident.
• Automatic Revocation: Consider automatically revoking Passkeys that have not been used for a long time, or upon certain events (e.g., after account recovery via a backup method).

5. Poor User Information and Education

Mistake: Implementing WebAuthn without adequately explaining to users what it is, how it works, why it's more secure, and how to use it.

Consequences: User confusion, resistance to new technology, increased support requests with questions like "what is this window?" or "where did my password go?".

How to avoid:

• Detailed Guides: Create clear step-by-step instructions and FAQs for users.
• Intuitive UX: The interface design for registration and authentication should be as simple and clear as possible.
• Explanatory Texts: Add brief explanations in the UI when a user encounters a WebAuthn request.
• Support Channels: Ensure that the support team is trained to work with WebAuthn and can promptly answer user questions.
• Benefits: Emphasize the benefits (convenience, security, no passwords) to encourage adoption.

By avoiding these common mistakes, you can ensure a smoother, more secure, and successful implementation of WebAuthn into your infrastructure and applications.

WebAuthn Practical Implementation Checklist

To ensure successful and secure implementation of WebAuthn (Passkeys) for your infrastructure and web applications, follow this step-by-step guide. This checklist covers key stages from planning to launch and support.

Stage 1: Planning and Architecture

1. Define the implementation goal:
   • Securing SSH access to servers?
   • Passwordless login for web applications?
   • Compliance with regulatory requirements (NIST, PCI DSS)?
   • Improving UX and reducing support load?
2. Choose the implementation approach:
   • Native SSH/PAM integration?
   • Custom implementation for web applications?
   • Using an Identity Provider (IdP)?
   • Hybrid approach?
3. Define the rpId and origin strategy:
   • Choose the root domain for rpId if subdomain support is required.
   • Ensure that origin always uses HTTPS.
4. Design access recovery mechanisms:
   • Provide for the registration of multiple Passkeys.
   • Define backup methods (e.g., backup codes, delayed email/SMS confirmation).
   • Develop a recovery procedure through support services.
5. Plan Passkey lifecycle management:
   • Mechanisms for users to view, rename, revoke, and delete keys.
   • Administrative tools for revoking keys.
6. Assess compatibility:
   • Target user browsers and operating systems.
   • Supported hardware authenticators (if applicable).

Stage 2: Implementation and Development

7. For SSH/PAM (if this approach is chosen):
   • Install libfido2 and pam_u2f.
   • Configure key registration with pamu2fcfg (locally or centrally).
   • Configure /etc/pam.d/sshd to use pam_u2f.so.
   • Configure /etc/ssh/sshd_config (ChallengeResponseAuthentication yes, UsePAM yes).
   • Test SSH access with a FIDO2 key.
8. For web applications (if this approach is chosen):
   • Select and integrate a server-side WebAuthn library (e.g., py_webauthn, @simplewebauthn/server).
   • Implement endpoints for generating registration options (GET /register/options).
   • Implement endpoints for verifying registration responses (POST /register/verify).
   • Implement endpoints for generating authentication options (GET /login/options).
   • Implement endpoints for verifying authentication responses (POST /login/verify).
   • Develop client-side JavaScript logic to interact with the browser's WebAuthn API (e.g., with @simplewebauthn/browser).
   • Ensure secure storage of Passkey metadata (credentialID, credentialPublicKey, counter) in your database.
9. For IdP integration (if this approach is chosen):
   • Register with the chosen IdP (Auth0, Okta, Keycloak).
   • Configure the IdP domain and your application in its control panel.
   • Enable WebAuthn/Passkeys support in IdP settings.
   • Integrate the IdP's SDK/API into your web application to redirect to IdP authentication pages.
   • Configure the callback URL for user return after successful authentication.
10. Ensure HTTPS: Verify that all WebAuthn-related endpoints are accessible only via HTTPS.

Stage 3: Testing and Deployment

11. Conduct comprehensive testing:
    • Test registration and authentication on various browsers (Chrome, Firefox, Safari, Edge).
    • Test on various platforms (Windows, macOS, Android, iOS).
    • Test with various authenticators (platform, cross-platform, hardware keys).
    • Test key loss and access recovery scenarios.
    • Test for validation errors (incorrect challenge, rpId, etc.).
12. Develop user documentation:
    • Step-by-step instructions for registering and using Passkeys.
    • FAQ for common questions and issues.
    • Instructions for access recovery.
13. Train support staff:
    • How WebAuthn works.
    • How to assist users with registration/authentication.
    • Access recovery procedures.
14. Implement logging and monitoring:
    • Log all registration and authentication events.
    • Monitor for anomalous login attempts or frequent errors.
15. Phased deployment:
    • Start with a pilot group of users.
    • Gradually expand availability to all users.
    • Initially offer WebAuthn as an option, not a mandatory method, to allow users to become accustomed to it.

Cost Calculation and Economics of WebAuthn Implementation

Implementing WebAuthn, like any other technological innovation, requires investment. However, in 2026, these investments are not only justified from a security perspective but also bring significant economic benefits. It is important to consider both direct and hidden costs, as well as potential savings.

Calculation Examples for Different Scenarios (2026)

Scenario 1: Small Startup (1,000 users, custom web application implementation)

A small startup with a limited budget and a strong technical team might decide to develop its own WebAuthn implementation for its web application to avoid monthly IdP payments and maintain full control.

• Development Costs (initial dev cost):
  • Estimate: 300 engineer hours (Backend + Frontend + QA).
  • Engineer rate (average for 2026 market): $120/hour.
  • Total: 300 * $120 = $36,000.
• Hardware Key Costs (optional):
  • If the startup decides to issue hardware keys (e.g., YubiKey FIDO2) to top management (10 people).
  • Cost of YubiKey 5 Series (2026): ~$60/unit.
  • Total: 10 * $60 = $600.
• Support and Maintenance Costs (annually):
  • Library support, bug fixes, updates, monitoring: ~80 hours/year.
  • Total: 80 * $120 = $9,600/year.
• Hidden Costs: Time for team training, testing, development of recovery mechanisms.

Total TCO estimate for 3 years: $36,000 (development) + $600 (hardware) + 3 * $9,600 (support) = $65,400.

Scenario 2: Medium SaaS Project (50,000 users, IdP solution)

A medium SaaS project, for which implementation speed, scalability, and reduction of operational authentication support costs are important, will most likely choose an IdP.

• Integration Costs (initial integration cost):
  • Estimate: 80 engineer hours (SDK integration, IdP configuration).
  • Engineer rate: $120/hour.
  • Total: 80 * $120 = $9,600.
• IdP License Costs (annually, 2026):
  • For example, Auth0 Enterprise Tier or Okta Workforce Identity for 50,000 MAU.
  • Estimate: $1,500 - $3,000 per month.
  • Total: $18,000 - $36,000/year. (Let's take the average of $27,000/year).
• Support Costs (annually):
  • Monitoring, minor configuration changes, interaction with IdP support: ~40 hours/year.
  • Total: 40 * $120 = $4,800/year.

Total TCO estimate for 3 years: $9,600 (integration) + 3 * $27,000 (licenses) + 3 * $4,800 (support) = $105,000.

Scenario 3: Large Enterprise (10,000 employees, hybrid approach)

A large enterprise with internal infrastructure and multiple applications will use a hybrid approach: PAM for servers and IdP for web applications.

• PAM/SSH Implementation Costs (initial dev cost):
  • Estimate: 120 engineer hours (planning, configuration, testing, documentation).
  • Engineer rate: $150/hour.
  • Total: 120 * $150 = $18,000.
• Hardware Key Costs:
  • Issuing 1 YubiKey (primary) to 10,000 employees + 1,000 backup keys for the pool.
  • Cost of YubiKey 5 Series (2026): ~$60/unit.
  • Total: (10,000 + 1,000) * $60 = $660,000.
• IdP Integration Costs (initial integration cost):
  • Estimate: 160 engineer hours (integration with corporate IdP, SSO configuration for multiple applications).
  • Engineer rate: $150/hour.
  • Total: 160 * $150 = $24,000.
• IdP License Costs (annually):
  • For 10,000 internal users.
  • Estimate: $5,000 - $10,000 per month.
  • Total: $60,000 - $120,000/year. (Let's take the average of $90,000/year).
• Support Costs (annually):
  • PAM Support: ~60 hours/year.
  • IdP Support: ~80 hours/year.
  • Total: (60+80) * $150 = $21,000/year.

Total TCO estimate for 3 years: $18,000 (PAM) + $660,000 (hardware) + $24,000 (IdP integration) + 3 * $90,000 (IdP licenses) + 3 * $21,000 (support) = $1,005,000.

Hidden Costs

• Staff Training: Time spent on training the IT team, support staff, and end-users.
• Procedure Development: Creation of operational documentation, recovery procedures, user instructions.
• Temporary Dual Support: Maintaining old authentication systems in parallel with WebAuthn during the transition period.
• Unforeseen Issues: Time spent resolving integration complexities, bugs, compatibility problems.
• Audit and Compliance: Costs for external audits to confirm compliance with security standards.

How to Optimize Costs

• Phased Implementation: Start with the most critical systems or a small group of users.
• Using Open-Source: For SSH/PAM, this is virtually free. For web applications, Keycloak (self-hosted IdP) can be used, which will reduce license fees but increase hosting and administration costs.
• In-house Training: Use internal experts to train the team and users, creating internal resources.
• Automation: Automate key registration and revocation processes to reduce manual effort.
• Thorough Planning: Detailed planning of architecture and integration from the outset helps avoid costly rework.
• Minimizing Hardware Keys: If possible, rely on Passkeys synchronized via cloud services (iCloud Keychain, Google Password Manager) to avoid mass purchase of physical devices.

Table with Calculation Examples (3-Year TCO Summary)

Economic Impact: Beyond direct costs, it's important to consider savings. WebAuthn significantly reduces the number of security incidents related to phishing and credential theft, saving millions of dollars on investigations, recovery, and reputational losses. The burden on support services for password resets is reduced. User productivity increases due to faster and more convenient login. In 2026, these benefits outweigh the initial investments, making WebAuthn not just a "good practice" but a necessity for any responsible business.

Cases and Examples of Successful WebAuthn Implementation

Let's consider several realistic scenarios demonstrating the practical application of WebAuthn (Passkeys) in various types of organizations. These examples illustrate how the technology solves specific security problems and improves user experience.

Case 1: Protecting internal servers of a large IT company's DevOps team

Problem:

A large IT company, "TechGiant," with over 500 DevOps engineers and system administrators, faced a growing risk of SSH key compromise. Despite using strong passwords and traditional 2FA (TOTP), there was a constant threat of phishing or key leakage through infected workstations. Security audits regularly indicated the need to strengthen authentication for accessing production servers and critical infrastructure.

The company also faced the challenge of managing hundreds of thousands of SSH keys, their rotation, and revocation, which required significant operational resources and was a source of errors.

Solution:

"TechGiant" decided to implement WebAuthn for all SSH accesses, using hardware FIDO2 YubiKeys as the primary authentication method. Native integration with PAM (Pluggable Authentication Modules) was chosen for all Linux servers. Each engineer received two hardware keys (primary and backup).

• Centralized Registration: An internal Python utility was developed, allowing engineers to register their YubiKeys via a web interface. The utility generated entries for u2f_keys, which were then automatically synchronized with a centralized LDAP directory and distributed to all servers via Ansible.
• PAM Configuration: The /etc/pam.d/sshd file was configured to require both successful authentication via a public SSH key and confirmation via YubiKey. This provided phishing-resistant two-factor authentication.
• Passwordless sudo: To enhance convenience and security, sudo was also configured to use a FIDO2 key instead of a password, reducing the number of passwords entered.
• Recovery Procedures: In case of losing both keys, the engineer had to undergo an enhanced identity verification procedure through HR and security services, after which their old keys were revoked, and new ones were issued.

Results:

• Zero Phishing Rate: In the 18 months following implementation, not a single successful phishing incident related to server access was recorded.
• Reduced Operational Costs: SSH key management became significantly simpler, as the private parts of the keys never leave the hardware authenticator. The need for regular SSH key rotation and complex distribution infrastructure was eliminated.
• Improved Compliance: The company easily passed audits for compliance with NIST SP 800-63B (AAL3) and PCI DSS standards, which was critical for its business operations.
• Increased Trust: Employees appreciated the enhanced level of security and convenience, as they no longer needed to remember complex passwords for sudo.

Case 2: Implementing Passkeys for an Online Education SaaS Platform

Problem:

The "EduSync" SaaS platform, with millions of students and instructors, faced a high load on its support service due to password resets (over 10,000 requests per month) and frequent complaints about a slow and inconvenient login process. Additionally, there were incidents of account compromise due to the use of weak passwords and phishing, which undermined trust in the platform.

Solution:

"EduSync" decided to implement Passkeys for its users, leveraging a ready-made Identity Provider (IdP) solution – Auth0, which already offered native WebAuthn support. This allowed for quick integration of the technology without significant costs for developing its own authentication system.

• Rapid Integration: The "EduSync" development team used the Auth0 SDK to integrate Passkeys into their React web interface and React Native mobile applications. The integration took only 3 weeks.
• Seamless UX: Users could now register Passkeys from their smartphones (via iCloud Keychain or Google Password Manager) or laptops. The login process became as simple as possible – it was enough to confirm login with biometrics or a PIN on their device.
• Flexible Options: For a transitional period, password login with 2FA remained an option, but Passkeys were actively promoted as the primary and recommended method.
• Passkey Management: A section was added to the "EduSync" user profile where students and instructors could view their registered Passkeys, give them descriptive names, and revoke them if necessary.
• Centralized Management: Auth0 provided a unified dashboard for managing all users and their credentials, including Passkeys, which significantly simplified administration.

Results:

• Reduced Password Reset Requests: The number of support requests related to password resets decreased by 65% within 6 months.
• Improved User Experience: Login speed decreased by an average of 70%, leading to increased user satisfaction and reduced churn.
• Enhanced Security: The number of compromised accounts related to phishing significantly decreased.
• Scalability: The authentication system easily scales with the growth of the platform's user base, requiring no additional effort from the "EduSync" team.
• Fast Time-to-Market: Thanks to the ready-made IdP solution, "EduSync" was able to quickly implement advanced authentication technology, outpacing competitors.

These cases demonstrate that WebAuthn is not just a theoretical concept, but a powerful practical tool capable of solving real security and convenience problems in various business scenarios.

Tools and Resources for Working with WebAuthn

Successful implementation of WebAuthn (Passkeys) requires the use of reliable tools and up-to-date resources. By 2026, the WebAuthn ecosystem has significantly evolved, offering a wide range of libraries, hardware solutions, and documentation.

1. Server-side WebAuthn Libraries

These libraries simplify the implementation of server-side logic for generating options and verifying responses from authenticators.

• Python:
  • fido2: Official library from Yubico, supports all aspects of FIDO2/WebAuthn. An excellent choice for deep integration.
  • py_webauthn: Another popular and well-maintained library, often used in projects.
• Node.js/TypeScript:
  • @simplewebauthn/server: One of the most popular and easy-to-use libraries, actively developed. Recommended for most projects.
• Go:
  • go-webauthn: A powerful and flexible library for Go applications.
• PHP:
  • web-authn/web-authn: A well-documented and maintained library for PHP.
• Java:
  • webauthn4j: A reliable implementation for the Java ecosystem.

2. Client-side JavaScript Libraries

These libraries simplify interaction with the browser's WebAuthn API.

• @simplewebauthn/browser: SimpleWebAuthn component for the client-side, perfectly complements the server-side.
• Native WebAuthn API: In most cases, you can directly use navigator.credentials.create() and navigator.credentials.get(), but libraries simplify working with it.

3. PAM Modules for Linux

For integrating WebAuthn with SSH and local authentication on Linux.

• pam_u2f: Primary PAM module for FIDO U2F/FIDO2 support. Requires libfido2.
• libfido2: A library providing low-level FIDO2 functions for Linux.

4. Identity Providers (IdP) with WebAuthn/Passkeys Support

Ready-made solutions that simplify the implementation and management of authentication.

• Auth0 (now part of Okta): A flexible identity management platform with broad support for WebAuthn and Passkeys.
• Okta: Market leader in Identity Management, offering robust solutions for enterprises, including WebAuthn.
• Keycloak: Open-source IdP that can be self-hosted. WebAuthn support is actively being developed.
• Azure Active Directory: For organizations using the Microsoft ecosystem, offers Passkeys support.
• AWS Cognito: AWS service for managing user identities, also supports FIDO2.

5. Hardware Authenticators (FIDO2 Keys)

Physical devices that can store Passkeys or act as authenticators.

• YubiKey 5 Series / Bio Series: Popular, reliable, and multi-functional keys from Yubico.
• SoloKeys: Open-source FIDO2 keys, offering a high level of transparency.
• Google Titan Security Key: Hardware keys from Google.
• Built-in Platform Authenticators: TPM modules in laptops, Secure Enclave in Apple devices, biometric scanners in smartphones – all of these can serve as authenticators for Passkeys.

6. Monitoring and Testing

• Browser Developer Tools: The Console and "Network" tab will help debug the client-side.
• Logging Systems: ELK Stack (Elasticsearch, Logstash, Kibana), Grafana Loki, Splunk for collecting and analyzing authentication logs.
• SIEM Systems: For centralized security event management and anomaly detection.
• FIDO Alliance Conformance Tools: For verifying your implementation's compliance with FIDO specifications.

7. Useful Links and Documentation

• FIDO Alliance - WebAuthn: Official WebAuthn page on the FIDO Alliance website.
• MDN Web Docs - Web Authentication API: Excellent documentation on the WebAuthn API.
• webauthn.io: Interactive WebAuthn demo, useful for understanding concepts.
• passkeys.dev: A resource dedicated to Passkeys, with guides and news.
• W3C Specifications:
  • Web Authentication: An API for accessing Stronger Authentication (Level 2)
  • Web Authentication: An API for accessing Stronger Authentication (Level 3) (current version for 2026)

By using these tools and resources, you can effectively implement and maintain WebAuthn in your environment, ensuring a high level of security and convenience.

Troubleshooting: Troubleshooting WebAuthn issues

Implementing WebAuthn, despite its standardization, can encounter a number of issues. Here we have compiled typical situations and methods for their diagnosis and resolution, relevant for 2026.

1. "Authenticator not recognized" or "No compatible authenticator found"

Description: The browser or operating system cannot detect or interact with a connected authenticator (e.g., YubiKey) or a platform authenticator (e.g., a built-in fingerprint scanner).

Possible causes and solutions:

• Physical connection: Ensure that the hardware key is correctly inserted into the USB port and is not damaged. Try another port.
• USB drivers: On Linux, ensure that you have the necessary udev rules installed for FIDO devices. These usually come with libfido2 or pam_u2f packages but may require manual configuration.

  
  # Пример файла udev-правил для YubiKey (может быть в /etc/udev/rules.d/70-u2f.rules)
  # KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1050", TAG+="uaccess"
              

  After changing the rules: sudo udevadm control --reload-rules && sudo udevadm trigger.
• Browser/OS support: Ensure that your browser and operating system are new enough for full WebAuthn and Passkeys support. By 2026, this is rare, but older versions can be an issue.
• Blocking by third-party extensions: Some browser extensions (e.g., ad blockers, VPNs) can interfere with WebAuthn. Try disabling them or using incognito mode.
• Authenticator damage: Rarely, but the authenticator might be damaged. Try another key if available.
• OS security settings: On some OSes (especially corporate ones), there might be policies blocking access to USB devices or biometric sensors.

2. "rpId mismatch error" or "The RP ID is not valid"

Description: An error indicating a mismatch between the rpId expected by the server and the rpId the browser is trying to use.

Possible causes and solutions:

• Domain mismatch: Ensure that the rpId passed in the generateRegistrationOptions/generateAuthenticationOptions request exactly matches the domain from which your application is served (or its root domain).

  
  // Пример: если ваше приложение на app.example.com, rpId должен быть example.com
  const rpId = 'example.com';
              

• Typos: Check for typos in the rpId on the server and in the client-side code.
• Protocol: Ensure your site runs over HTTPS. WebAuthn strictly requires HTTPS.
• Subdomains: If you want the Passkey to work across all subdomains, the rpId must be the root domain. If rpId is set to app.example.com, it will not work on sub.app.example.com.

3. "The request is not allowed by the user agent or the platform in the current context" (SecurityError)

Description: A general security error indicating that the browser or platform has disallowed the WebAuthn operation.

Possible causes and solutions:

• HTTP instead of HTTPS: The most common reason. WebAuthn only works on HTTPS (or localhost for development).
• iframe context: If WebAuthn is called from an iframe, ensure that the iframe has the necessary allow="publickey-credentials-get" attributes.

  
  <iframe src="your_webauthn_page.html" allow="publickey-credentials-get"></iframe>
              

• Browser limitations: Some browsers may have additional security restrictions (e.g., requiring active window focus, user interaction).
• Incorrect Origin: Ensure that the origin you pass on the server-side for verification exactly matches window.location.origin on the client.

4. SSH authentication with FIDO2 key not working

Description: After configuring pam_u2f, you cannot log in via SSH or are not prompted to touch the key.

Possible causes and solutions:

• Incorrect PAM configuration:
  • Check /etc/pam.d/sshd. The line with pam_u2f.so should be at the beginning of the auth section.
  • Ensure that the path to authfile (/etc/Yubico/u2f_keys or ~/.config/Yubico/u2f_keys) is correct and the file exists.
  • Check permissions for the u2f_keys file. It must be readable by the user under which the SSH daemon runs (usually root or sshd).
• Incorrect SSHD configuration:
  • Check /etc/ssh/sshd_config. Ensure that UsePAM yes, ChallengeResponseAuthentication yes, and AuthenticationMethods includes keyboard-interactive.
  • After any changes to sshd_config or PAM, restart the SSH daemon: sudo systemctl restart sshd.
• Incorrectly registered key: Ensure that the key was registered for the correct user using the command pamu2fcfg -u <username>.
• Logs: Check the SSH daemon logs for detailed error information:

  
  sudo journalctl -xe | grep sshd
  sudo tail -f /var/log/auth.log # Для Debian/Ubuntu
  sudo tail -f /var/log/secure # Для RHEL/CentOS/Fedora
              

  Look for messages from pam_u2f. If you added debug to the PAM configuration, there will be more information.

5. "The credential was registered with a different RP ID"

Description: When attempting to authenticate a Passkey that was registered with one rpId, it is being used with a different rpId.

Possible causes and solutions:

• Different RP IDs: Passkeys are strictly tied to the rpId. If you changed the rpId for your application, old Passkeys will not work. Users will have to register new ones.
• Development/Testing: When moving from a test domain to production, the rpId will change. Ensure that you register new Passkeys on the production domain.

6. Issues with counter update (Counter)

Description: Server-side verification fails because the counter returned by the authenticator is not greater than the previously saved value.

Possible causes and solutions:

• Incorrect counter saving: Ensure that you correctly save and update the authenticator.counter value in your database after each successful authentication.
• Replay attack: This could be an indicator of a real replay attack. Investigate thoroughly.
• Authenticator reset: If the authenticator was reset or cloned, the counter might be incorrect.

When to contact support

• IdP issues: If you are using Auth0, Okta, or another IdP and encounter errors not related to your integration (e.g., issues with their API, service unavailability).
• Hardware key issues: If you suspect that the hardware key itself is faulty (unresponsive, not detected by the OS) and you have ruled out driver/port issues.
• Unclear cryptographic errors: If server-side WebAuthn libraries report errors related to cryptography or signatures, and you cannot find a solution in the documentation or community.

Thorough logging and step-by-step debugging are your best friends when troubleshooting WebAuthn issues. Use browser developer tools, Linux system logs, and library documentation.

FAQ: Frequently Asked Questions about WebAuthn (Passkeys)

What are Passkeys?

Passkeys (pass-through keys) are a new authentication standard based on WebAuthn and the FIDO2 protocol, which allows users to log in to websites and applications without passwords. Instead of a password, a pair of cryptographic keys is used: the public key is stored on the server, and the private key is stored on the user's device (smartphone, laptop, hardware key) and protected by biometrics or a PIN. Passkeys are resistant to phishing and synchronize between user devices via cloud services (e.g., iCloud Keychain, Google Password Manager), making login seamless and secure.

How is WebAuthn better than traditional 2FA?

WebAuthn (Passkeys) surpasses traditional 2FA (two-factor authentication) in several ways. Firstly, it completely eliminates passwords, whereas 2FA only complements them. Secondly, WebAuthn is inherently resistant to phishing because authentication is tied to a specific domain. Traditional 2FA methods, such as SMS codes or even TOTP, can be intercepted or tricked using sophisticated phishing attacks. WebAuthn also offers a significantly better user experience, as it often requires only one action (e.g., touching a fingerprint sensor) to log in.

Can WebAuthn be used without a hardware key?

Yes, absolutely. In 2026, most Passkey implementations rely on "platform authenticators" – these are security features built into your device, such as fingerprint scanners, facial recognition systems (Face ID, Windows Hello), or device PINs. Private keys are stored in a secure area of the device (e.g., TPM, Secure Enclave) and can be synchronized between your devices via cloud services, creating a Passkey. Hardware keys (like YubiKey) are "cross-platform authenticators" and still remain an excellent choice for additional security or in corporate environments, but they are not mandatory.

How to ensure access recovery in case of key loss?

Access recovery is a critical aspect. It is recommended to register multiple Passkeys for a single account, using different devices. For example, one Passkey on a smartphone, another on a laptop, and possibly a hardware key. Additionally, secure backup recovery methods should be provided, such as one-time backup codes that the user can print and store in a safe place. For critically important systems, a recovery procedure can be implemented through support services with enhanced identity verification, including a delay before access activation.

Is WebAuthn compatible with older browsers?

By 2026, WebAuthn is supported by the vast majority of modern browsers (Chrome, Firefox, Safari, Edge) and operating systems. However, older versions of browsers or OS may not have full support. When implementing WebAuthn, it is generally recommended to offer it as an option, retaining traditional methods (password + 2FA) for users whose devices or browsers do not support this technology. Gradual transition and informing users about the need to update software are key to success.

Is anything stored on the server?

Yes, the public part of the Passkey (credentialPublicKey), as well as its unique identifier (credentialID) and usage counter (counter), are stored on the server. The private key never leaves the user's authenticator. The server uses the public key to verify the cryptographic signature created by the authenticator's private key, confirming the user's identity. It is important to securely store this data in your database, linked to the user's account.

How does WebAuthn protect against phishing?

WebAuthn protects against phishing by binding authentication to a specific domain (rpId) and origin (origin). When you register a Passkey for example.com, the authenticator generates a signature that works only for that domain. If an attacker creates a phishing site examp1e.com, your Passkey will not work on it because the domain does not match. The browser and authenticator verify this match, preventing the transmission of credentials to a fake resource.

What are the risks of implementing WebAuthn?

The main risks are not related to the WebAuthn technology itself, but to its incorrect implementation. This includes: improper validation of authenticator responses (vulnerability to replay attacks), lack of adequate access recovery mechanisms (user lockout), poor user experience (non-adoption of the technology), and ignoring the key lifecycle (inability to revoke compromised keys). There is also a risk that users may lose all their authenticators without backups.

What is the role of an IdP in WebAuthn?

Identity Providers (IdP) such as Auth0, Okta, or Keycloak simplify WebAuthn implementation by taking on much of the complexity. They provide ready-to-use APIs and SDKs for integration, manage WebAuthn server-side logic, store Passkey metadata, and ensure centralized user management. IdPs also offer additional features such as single sign-on (SSO), other MFA methods, auditing, and analytics, which significantly accelerate deployment and reduce the burden on the development team.

Can one key be used for multiple services?

Yes, a single physical FIDO2 key (e.g., YubiKey) can be used to register Passkeys for many different services. Each service will have its unique rpId, and the key will generate unique key pairs for each of them. As for Passkeys synchronized via cloud services (e.g., iCloud Keychain), they are also designed for use across multiple services, providing seamless login from any of your devices that support synchronization.

Conclusion

In 2026, the implementation of WebAuthn (Passkeys) ceased to be merely a "good practice" and became a necessary condition for ensuring robust security of digital assets and a comfortable user experience. The elimination of passwords, resistance to phishing, and seamless cross-platform authentication make Passkeys a cornerstone of modern cybersecurity strategy.

As we have thoroughly discussed, there are various implementation paths: from native integration with SSH/PAM for protecting critical infrastructure on Linux to using powerful Identity Providers (IdP) or custom development for web applications. Each approach has its advantages and disadvantages, and the choice of the optimal solution depends on your organization's specific requirements, budget, and available resources.

Final Recommendations:

• Don't delay implementation: Password-related threats are only growing. The sooner you start transitioning to WebAuthn, the faster you can protect your users and infrastructure.
• Start with a pilot: Implement WebAuthn gradually, starting with a small group of users or less critical systems. This will allow you to refine processes and gather feedback.
• Prioritize security and UX: Ensure that your WebAuthn implementation is not only secure (proper validation, protection against replay attacks) but also user-friendly for end-users. Poor UX can sabotage all efforts.
• Plan for access recovery: This is the most important aspect, often underestimated. Ensure that users have clear and secure paths for access recovery in case of losing all Passkeys.
• Invest in training: Train both your technical team and end-users. Understanding how Passkeys work and why they are more secure will significantly increase their adoption.
• Use proven tools: Rely on mature server-side libraries, reliable IdPs, and well-known hardware authenticators. Do not try to reinvent the wheel in the field of cryptography.
• Monitoring and auditing: Set up detailed logging and monitoring of all authentication events. This will help identify anomalies and ensure compliance with regulatory requirements.

Next steps for the reader:

Now that you have a full understanding of WebAuthn and Passkeys, it's time to act:

1. Conduct an internal audit: Assess the current state of authentication security in your organization.
2. Form a working group: Involve DevOps, Backend developers, and security specialists.
3. Choose a pilot project: Identify where WebAuthn implementation will bring the greatest and fastest benefit.
4. Start experimenting: Use the code examples and tools provided in this guide to create a prototype.
5. Stay informed: The WebAuthn ecosystem continues to evolve. Follow FIDO Alliance news and browser updates.

Implementing WebAuthn is not just a technical project; it's a strategic decision that will strengthen your position in the constantly evolving landscape of cyber threats and provide your users with the most modern and secure way to interact with the digital world.