But that raises another question: how do you make sure the person connecting is actually who they claim to be? A conventional password can be stolen, and an extra SMS code does not always stop phishing.

Smart Lab decided to explore a different approach: using a FIDO2 smart card to connect to the corporate network. Instead of remembering a VPN password or waiting for a text message, the user verifies their identity with the card and its PIN.

For now, this is a prototype built with open technologies. What makes the architecture interesting is the combination of hardware-based authentication and Zero Trust principles: being allowed to access one corporate resource does not automatically mean gaining access to the entire network.

Why remove the password?

The traditional username-and-password approach has a longstanding weakness. A password has to be stored somewhere, entered regularly, and sometimes changed. More importantly, a user can be tricked into giving it to someone else.

Adding a second factor makes an attack harder, but the level of protection depends on how that factor works. A one-time code, for example, can be captured through a fake login page. The employee believes they are signing in to a corporate service, while in reality they are handing the code to someone trying to access the account.

We discussed this in our article “Why SMS Codes Are No Longer Enough to Protect Business Accounts”. With a corporate VPN, the consequences can be particularly serious: a compromised account may provide access to systems that are not reachable from the public internet at all.

Smart Lab proposes using a FIDO2-enabled smart card. In this model, two authentication factors are combined in one device: possession of the physical card and knowledge of its PIN.

Unlike a regular account password, the PIN is checked by the authenticator itself and is not sent to the corporate server. The private cryptographic key used to authenticate the user also stays inside the protected device.

So what happens behind the scenes?

When a user registers the smart card with the system, a cryptographic key pair is created. The public key is provided to the authentication service; the private key remains on the card. During subsequent sign-ins, the server sends a random challenge, and the card signs the relevant authentication data with its private key. The user first authorizes that operation by entering the PIN.

The server then verifies the signature and checks that the required user verification took place. It does not need the user’s password or any other shared secret.

The Smart Lab prototype uses ECDSA with the secp256r1 elliptic curve, also known as NIST P-256. In WebAuthn, the corresponding algorithm is ES256. It is widely supported by modern cryptographic systems and suitable for hardware authenticators.

There is another important detail. WebAuthn binds authentication to a specific service. If a user lands on a fake domain, the attacker cannot simply obtain an authentication response that will work for the legitimate service, as they might with a stolen one-time code.

What is behind the FIDO2 VPN prototype?

A smart card alone cannot provide remote network access. It can authenticate a person, but it cannot create a VPN tunnel or decide which servers a particular employee should be allowed to reach.

That is why Smart Lab assembled the prototype from several components, each handling a different part of the problem.

Authelia handles authentication. It supports WebAuthn and can act as an identity provider through OpenID Connect (OIDC). This is how the VPN system obtains confirmation of the user’s identity.

NetBird is used to organize the private network. Built around WireGuard, it manages secure connections, registers devices, brings them together in a private network, and applies access policies.

WireGuard encrypts network traffic. Devices establish a direct connection when possible, while NetBird provides signalling and relay components for more restrictive network environments.

Caddy serves as the reverse proxy, providing secure HTTPS access to the system’s web services. The internal applications themselves do not have to be exposed directly to the internet.

All these services are deployed with Docker on a Raspberry Pi 4. The setup has separate services for Authelia, NetBird management, the web dashboard, signalling, traffic relay, and a network client that acts as a gateway to internal resources.

Here, the Raspberry Pi is an experimental platform, not a recommendation to run every corporate VPN on a small single-board computer. Any production deployment would require a separate assessment of workload, redundancy, and fault tolerance.

One particularly interesting resource in the test architecture is a private server running Ollama, with a web interface for working with language models. This is a practical scenario: a company might use a local AI system for internal tasks without wanting it to be publicly accessible over the internet.

In that setup, the VPN provides the path to the server, while FIDO2 confirms who is trying to connect.

Prototype architecture: from smart card to internal server

In this prototype, user authentication and data transmission are separate processes. The FIDO2 smart card verifies the user, Authelia supplies the identity information, NetBird applies access policies, and WireGuard provides an encrypted network connection.

Stage	Component	What happens
1. Identity verification	FIDO2 smart card + PIN	The user verifies their identity locally, and the smart card performs a cryptographic signature operation.
2. Authentication check	Authelia / WebAuthn	The service checks the authentication response and provides the verified identity through OIDC.
3. Access authorization	NetBird	The system authorizes the user and device and applies network access policies.
4. Device connection	NetBird client	The employee’s computer connects to the private network under the permitted rules.
5. Secure tunnel	WireGuard	An encrypted connection is established between permitted peers.
6. Resource access	Internal server	The user can reach only the resources permitted by policy, such as the private Ollama server.

Caddy separately provides HTTPS and routes web requests to the management and authentication services.

How an employee would connect

From the employee’s perspective, the process is intended to stay fairly simple.

They launch the NetBird client on their computer. If authentication is required, the system redirects them to Authelia. Instead of entering a regular corporate password, they use a FIDO2 smart card.

The employee connects the card to a compatible reader, enters the PIN, and confirms the sign-in. After successful verification, the identity service passes the necessary authentication information to NetBird through OIDC.

From there, the network components take over: the device is authorized, a secure WireGuard connection is established, and the relevant access policies are applied.

That may sound more complicated than an ordinary password-based VPN, but most of the complexity sits behind the scenes. The employee sees a sign-in page and uses their card.

There is a practical benefit for administrators as well. They do not have to open the entire internal network to every VPN user.

For example, an employee might be allowed to reach one internal web application, while a system administrator has access to specified servers. An external contractor could be given access to a single resource for the duration of a project, without being able to reach the rest of the infrastructure.

This is where Zero Trust comes in: each user and device receives only the permissions needed for its work. In the Smart Lab prototype, these rules are intended to be implemented through NetBird policies.

FIDO2 does not provide Zero Trust by itself. It provides a stronger way to verify identity. Assigning permissions, assessing devices, and restricting network connections are separate tasks.

There is one more possibility. If the company uses multiple internal web applications, the architecture could later be extended towards single sign-on through OIDC. This would allow verified identity information to be reused wherever those applications support the relevant integration.

Next steps

The project is still a prototype. Having a defined architecture does not mean that the system has been validated for production use.

One important question concerns Authelia itself. The configuration uses FIDO2 with local PIN verification to enable sign-in without a conventional password. In the Authelia version described in the technical materials, the mechanism that treats this form of authentication as satisfying the two-factor requirement has experimental status.

Compatibility with the specific smart card, user verification behaviour, and the system’s operation therefore need careful testing — particularly across operating systems, card readers, and browsers.

Another important scenario is a lost card.

The PIN makes a lost card harder for an unauthorized person to use, but it is not enough on its own. An administrator needs a way to prevent new sign-ins with that authenticator, issue a replacement card, and terminate active sessions when necessary.

That last point matters. Revoking an authenticator does not necessarily end an already established VPN connection immediately. Such cases require appropriate session and device management mechanisms.

The team will also need to check what happens if the authentication server or another infrastructure component becomes temporarily unavailable. A small experimental setup is one thing; a company that depends on remote access every working day is another.

Everyday usability is another open question. Will the sign-in process work equally well on different computers? How easy will it be to issue new cards? How can access be recovered without weakening the security model?

The answers will help determine how close this architecture is to practical deployment.

What Smart Lab hopes to learn

The central question behind this prototype is whether FIDO2 hardware authentication can become the primary way to enter a protected corporate network, rather than merely an extra check after a password.

The chosen architecture makes it possible to investigate that without building every component from scratch. Authelia handles identity, NetBird manages the private network, and WireGuard protects the traffic. The smart card and PIN verify the user.

The private AI server is a useful example. Companies increasingly need remote access not only to files or accounting systems, but also to their own applications, analytics platforms, and AI tools. Not every service should be publicly exposed, even when it has a conventional sign-in mechanism.

Can that access be provided without a corporate password while keeping it manageable and convenient? That is what Smart Lab is trying to find out.

It is too early to call this a finished product or claim results from production testing. Even so, the prototype illustrates a promising use of FIDO2: moving beyond the protection of individual accounts towards authenticating users who need access to an entire corporate network.

Related reading

Passwordless Authentication: Why Businesses Are Moving Away from Passwords →

Phishing Protection for Business →

Hardware Security Tokens for Electronic Signatures and FIDO2 Authentication →

Corporate authentication

Looking to secure remote access to your systems?

Smart Lab can help assess your current authentication methods, risks associated with internal system access, and where FIDO2 might fit. The VPN architecture described in this article is still at the prototype stage.

Discuss secure access →