Across government and enterprise environments, organizations are investing heavily in authentication modernization. Passkey rollouts, FIDO2 security keys and phishing-resistant authentication are now central topics in identity strategy.
In many cases, that investment still includes issuing security keys, hardware tokens, or other separate devices to replace passwords and one-time passcodes. That is an important step forward. A cryptographic credential is significantly stronger than a password or a code that can be typed into a phishing site.
But as organizations plan large-scale passwordless deployments, one question deserves more attention: where should the credential actually live?
Should authentication depend on a separate device that users must carry, replace, and support, or should it use the trusted hardware already built into the endpoint being used to access the service?
The answer has implications for security, user experience, operational cost, and the long-term success of passwordless authentication in the public sector.
From Tokens to Passkeys
For many years, hardware tokens represented a major security improvement over passwords alone. Some generate one-time passcodes that users enter along with a PIN before accessing an online service. These solutions helped raise the security bar and served organizations well for decades.
The challenge is that any code displayed to a user can also be disclosed by that user, intentionally or unintentionally. Modern phishing kits automate the theft of credentials and authentication codes in real time. These attacks often occur during exactly the situations where step-up authentication is intended to provide protection, such as logins from unfamiliar devices or remote locations.
The industry response has largely been the adoption of FIDO-based authentication and passkeys. Instead of asking the user to type a shared secret, a cryptographic credential signs a challenge that is tied to the legitimate website or application. There is no code to enter and nothing useful for a phishing site to collect.
Passkeys are part of this broader movement. In practical terms, they replace passwords with cryptographic credentials that can be stored in a dedicated security key, a smartphone, or the user endpoint. The objective is the same: remove shared secrets, reduce phishing risk, and simplify authentication for legitimate users.
Organizations moving from passcodes to phishing-resistant authentication are moving in the right direction. The next question is how to roll it out in a way that is secure, manageable, and practical at scale.
Weak Fallback Methods Cap the Value of a Passkey Rollout
Many organizations support multiple forms of step-up authentication and allow users to choose the method that is most convenient for them. Flexibility can improve adoption, but it can also introduce risk.
If users can choose between a phishing-resistant credential and weaker alternatives such as SMS verification or knowledge-based questions, the overall security posture becomes constrained by the least secure methods that remain available.
The goal of modernization should not simply be to offer more authentication choices. The goal should be to ensure that the available methods provide consistent protection against phishing, credential theft, and account takeover.
This matters during passkey rollouts as well. If passkeys are introduced but weaker fallback methods remain broadly available, the organization may not realize the full security value of the investment.
Where the Credential Should Live
Once an organization decides to deploy hardware-backed cryptographic authentication, the next question is often overlooked: where should that credential reside?
A dedicated security token is a separate device. It must be purchased, distributed, inventoried, replaced when lost, and carried by the user. In large organizations, a token-based passkey rollout can mean thousands of additional devices that must be issued, tracked, supported, and eventually refreshed.
That cost is not a vendor talking point. Microsoft, whose own platform is at the centre of most passkey deployments, states it directly in its guidance: security keys provide strong security, but they can increase costs for equipment, training and help desk support, particularly when users lose their physical keys and need account recovery. Its updated guidance in July 2026 is blunter still. A lost key, a damaged authenticator, or a misconfigured restriction becomes an account-access incident, and help desk staff need a tested method to identify the registered credential, remove it, verify the user, and restore access.
Every one of those steps is work created by the decision to put the credential on a separate object. It is worth weighing at the point of procurement rather than discovering it at the service desk in year two, because it does not appear on the purchase order.
The device most employees already use, whether a laptop, tablet, or smartphone, also contains hardware-based security capabilities. Virtually every enterprise laptop shipped in the past decade includes a Trusted Platform Module, or TPM, designed to protect cryptographic keys. Modern smartphones provide similar capabilities through dedicated security hardware.
This is not a Windows-only proposition. The same approach runs on Windows, macOS, and smartphones, each using its own security hardware which matters where the fleet is mixed, or where clinical and field staff work mainly from a phone.
This makes the endpoint a natural candidate for holding the credential. Rather than introducing another device to manage, organizations can leverage the trusted hardware that already exists within the device being used for access.
Some passkey implementations rely on external security keys or mobile devices. Others leverage hardware already embedded within the endpoint. Both approaches improve security compared to passwords, but they create very different operational and user experiences.
The closer the credential is tied to the endpoint itself, the easier it becomes to combine strong authentication, device trust, and transparent user access.
Why Endpoint-Bound Credentials Are Different
A portable hardware token can authenticate a user from almost any computer. That flexibility can be useful, but it also means the same credential may be presented from a managed workstation, a personal laptop, or an unmanaged computer.
A TPM-bound credential allows the organization to make a stronger claim. It can connect the user, the device, and the state of that device. This gives administrators a better basis for access decisions, particularly when sensitive systems are being accessed remotely.
That additional context matters. Government and healthcare environments do not only need to know that the right person has authenticated. They also need confidence that the person is using a trusted, protected, and managed endpoint.
Why the User Need Not Be Involved at All
When the credential is held in the endpoint, authentication can happen with NO USER ACTION at all.
That is worth stating precisely, because most endpoint-based passkey implementations still prompt a PIN, a fingerprint, a face each time a service is accessed. The prompt is there because the credential has no way of knowing whether the right person is still in front of the machine.
An endpoint that verified the user at power-on, with full multi-factor authentication, and that keeps confirming their presence while they work, does know. The credential is available while that holds and unavailable the moment it stops. So there is nothing left to ask. Nothing appears on screen, nothing is typed, nothing is approved. The employee opens the laptop and works.
Attacks Have Moved from the Login to the Session
There is a second problem here and it is now the larger one. Every authentication method in common use passwords, one-time passcodes, security keys, passkeys proves the user once, at the door. After that, access rides on a session cookie, and that cookie carries the user through the rest of the day. Attackers have followed. Rather than defeating the login, they take the session behind it, which is why phishing-resistant login on its own has not ended account takeover.
A security key cannot help here. It proves a moment and once that moment has passed the key sits idle in a pocket or a USB port. A credential held in the endpoint is still there, still bound to the same verified user on the same verified device, so the proof continues while the person is working not only when they arrive.
Beyond Cookie-Based Device Recognition
Many organizations attempt to reduce repeated authentication prompts by recognizing trusted devices. In some cases, this recognition relies on browser cookies or other software-based identifiers.
That approach can improve convenience but software-based identifiers can potentially be copied, stolen or replayed by attackers.
A stronger approach is to bind trust directly to hardware-backed credentials stored within the device TPM or equivalent security hardware. In that model, trust is anchored to the endpoint itself rather than to a browser artifact. The result is a more phishing-resistant and tamper-resistant form of device recognition.
What Changes Operationally
The impact extends beyond security. For large-scale passwordless and passkey deployments, endpoint-bound credentials can reduce complexity in several ways:
- No separate authentication device to purchase, distribute, track, or replace.
- Reduced administrative overhead associated with token lifecycle management.
- Fewer help desk calls related to lost, damaged, expired, or unsynchronized tokens.
- Stronger resistance to phishing because there are no codes to display, share, or enter.
- The ability to combine user identity and device trust within a single authentication framework.
- A simpler user experience that reduces friction while maintaining strong security.
Consider a nurse accessing a healthcare application from a managed laptop, or a government employee connecting remotely from home. Neither wants to search for a token, wait for a verification code, or contact the help desk because a device was lost or expired.
There is an asymmetry here that is easy to miss. When a security key is lost, nothing else is wrong. The employee has their laptop, their applications, and their working day, and the only thing standing between them and all of it is a missing object whose sole purpose was authentication. That help desk call exists entirely because of the authentication design.
When the endpoint itself is lost or broken, the employee cannot work regardless of how they authenticate. IT is already involved, a replacement machine is already being issued, and re-establishing the credential is one more step inside a process that was going to happen anyway. Endpoint-bound credentials still need a defined recovery path, and any serious evaluation should ask to see it. The difference is how often it has to be used.
Importantly, this does not require organizations to abandon existing investments. Hardware tokens already deployed can continue to function, and modern FIDO2 security keys remain valuable tools in many environments. The question is how future investments should be prioritized as passkey rollouts expand.
Ontario’s Opportunity
WinMagic is headquartered in Ontario and has spent nearly three decades focused on endpoint security, disk encryption, pre-boot authentication, and identity protection.
That experience has shaped our view that the endpoint itself can play a much larger role in modern authentication than many organizations realize.
Ontario’s public-sector organizations, including Ontario Health and other provincial agencies, support millions of citizens and protect some of Canada’s most important digital assets. Decisions being made today about authentication, passkeys, and remote access will influence both security and operational efficiency for years to come.
As these investments are evaluated, one question deserves consideration:
If we were designing a large-scale passwordless environment today, would we issue employees another device to hold their passkey and authentication credential, or would we leverage the trusted hardware already built into the endpoints they use every day?
Modernization is not always about adding new technology. Sometimes it means reassessing an established approach and determining whether a better balance of security, usability, and cost is now available.
We welcome that conversation and the opportunity to contribute technical insight to help Ontario continue advancing secure and user-friendly digital services.
