Many authentication platforms remove passwords from the user experience while continuing to rely on stored credentials behind the scenes, and understanding that difference matters for any organization evaluating passwordless authentication in a regulated environment.
Passwordless authentication has become the direction most organizations are moving toward, with passkeys now supported across the major platforms, biometric sign-in in everyday use, and few security teams still willing to argue that passwords represent the future of enterprise identity. As those same organizations work out what passwordless means for them, one question tends to go unasked, which is where the password went. In many deployments it never disappeared at all; instead it moved somewhere the user no longer sees it, and that is a very different thing from being removed.
That distinction sits at the center of the conversation, because taking passwords off the login screen is not the same undertaking as taking them out of the authentication architecture, and a good number of solutions improve the experience a person has while continuing to depend on stored, reusable credentials held somewhere inside the environment. For an organization working to reduce phishing and credential theft, understanding where that credential lives is worth the attention it takes.
Passwordless login does not always mean passwordless authentication
The most common passwordless experience will be familiar to anyone who has used it, whether that means unlocking a device with a fingerprint, approving a sign-in request on a phone, or authenticating with a passkey, and from the user's point of view the password has genuinely gone. Behind that experience, the organization may still be holding passwords in Active Directory, synchronizing credentials across identity platforms, keeping them inside a vault, or leaning on them as part of the recovery process when a device is lost or replaced, so that the login has changed while the authentication model underneath it frequently has not.
None of this diminishes what passkeys and modern methods achieve, since they represent a substantial gain in both security and usability over traditional passwords, and the point being made here is a narrower one. The word passwordless can describe architectures that differ considerably from one another, and those differences begin to matter a great deal once the organization doing the evaluating operates under regulatory expectations.
Recovery deserves as much attention as authentication
Security discussions tend to concentrate on the primary login, and yet attackers frequently choose to target the account recovery path instead, because that is often where the weaker link sits. A large number of passwordless deployments still fall back on a password, a one-time passcode, or a set of security questions whenever a user loses a device, replaces a phone, or cannot complete the main authentication flow, which leaves the strong method protecting everyday access while the recovery route continues to rely on a reusable credential.
That arrangement does not by itself make a product insecure, but it does mean the password remains part of the organization's security architecture, and if recovering an account ultimately comes down to a password, then removing it from the login screen has not removed it from the environment in any meaningful sense.
The real question is where the secret lives
Most conversations about passwordless authentication settle on whether users are still typing passwords, when the more revealing question, at least from a security standpoint, is whether a reusable secret continues to exist anywhere in the first place. Passkeys that synchronize across devices are protected by the cloud identity that manages them, and that identity carries its own authentication and recovery mechanisms that become part of the picture. Password managers improve credential hygiene by generating strong, unique passwords and removing reuse, and in doing so they also gather those credentials together inside a single encrypted vault. Legacy enterprise applications, for their part, often continue to expect a password even when a newer method has been placed in front of them.
Each of these approaches is an improvement on passwords used alone, and none of them deserves to be dismissed, yet together they make the architectural distinction plain. Removing a password from the interface a user sees is not the same as removing the stored credential from the environment that surrounds it, and for as long as a reusable credential exists somewhere, it remains something an attacker can attempt to steal, to recover, or to replay.
A better way to evaluate passwordless authentication
Rather than asking whether a given solution is passwordless, an organization is better served by working through a more practical set of questions:
- Does a reusable credential still exist?
- Where is it stored?
- What protects it?
- What happens if the identity platform, password vault, or directory service is compromised?
- What happens if an attacker fully compromises a user's device?
The answers to those questions reveal considerably more about the underlying security architecture than the login experience on its own ever could, and they explain why two platforms can both advertise passwordless authentication while operating on security models that have very little in common.
Why this matters in regulated industries
For a large share of consumer applications, simply reducing how often passwords are used already counts as a meaningful improvement, and there is nothing wrong with treating it that way. Banks, government agencies, healthcare providers, and the operators of critical infrastructure work under a different set of expectations, since they are required to understand where credentials exist across their estate, to keep unnecessary attack surface to a minimum, and to demonstrate strong identity controls during security assessments and regulatory audits.
Viewed in that light, a centralized repository of reusable credentials is not merely one more piece of infrastructure to maintain, because depending on the organization it can also be an attractive target for an attacker and an area that auditors expect a security team to understand and defend. The Verizon 2025 Data Breach Investigations Report reflects the same pattern, showing compromised credentials continuing to play a significant part in breach activity even as authentication technology improves, which is a reminder that the way credentials are stored still carries as much weight as the way users authenticate.
Looking beyond the login screen
Passkeys, biometrics, and phishing-resistant authentication represent a genuine step forward for enterprise identity, and organizations have every reason to keep adopting them. Evaluating passwordless authentication properly, though, calls for looking past the login experience to the architecture behind it, because some designs remove the password from the user while continuing to store a reusable credential elsewhere, whereas others remove the stored reusable secret altogether by deriving a credential cryptographically only at the moment authentication takes place, leaving no persistent password to retrieve, steal, or expose. The difference between those two designs is architectural, and it is precisely the kind of difference a serious security review is meant to bring to the surface.
How Salina approaches it
Salina is built around that second design. It gives users passwordless access to enterprise applications through biometrics and mobile approvals, and it does so without relying on a central password vault, because rather than storing reusable credentials it derives the secret it needs on demand at the moment of authentication and retains no persistent copy once that authentication is complete. Two cryptographic mechanisms make this possible, working together so that the secret is both divided and short-lived:
- Multi-party computation (MPC) splits secret material across separate parties, so that no single component ever holds the complete secret.
- Oblivious pseudorandom functions (OPRF) derive the authentication secret without revealing it or persisting it anywhere it could later be recovered.
Because the secret is computed only at the point it is needed, sensitive material is never exposed to the user or left sitting on the device, and the single point of compromise that a vault or a directory represents is taken out of the equation. The authentication flows themselves are cryptographically validated, which closes off the phishing, replay, and credential-theft techniques that depend on there being a reusable secret to capture in the first place. Salina is designed to work alongside an organization's existing identity infrastructure rather than replacing it, and it supports both modern and legacy environments, so that, where an older system still insists on a password, Salina manages that credential on the organization's behalf instead of asking a person to remember or reuse one, and it does so without standing up a central store of reusable secrets.
Read against the questions raised earlier, the architecture answers them directly, since there is no central vault standing ready to be breached and no reusable secret sitting at rest for an attacker to lift, and even a device that has been fully compromised gives up no complete secret to recover, because the secret was divided across parties and never written down in the first place.
The question worth asking
Before anyone describes an authentication platform as passwordless, there is one question that settles the matter more honestly than the login screen can, which is whether a reusable secret still exists anywhere once the user has stopped entering a password. For an organization making identity decisions it expects to live with for years, the answer to that question will say a great deal more about how secure the platform really is than the login experience ever will, and it is the question Salina was built to answer.
Evaluating passwordless authentication for a regulated environment? Contact us to see how Salina fits alongside your existing identity infrastructure.