The password is still one of the attacker’s favourite targets
Passwords can be phished, sprayed, reused after a breach somewhere else, and exposed wherever people type, store or share them. Stronger rules make a password harder to guess. They do not remove the credential an attacker is trying to obtain.
The strongest thing you can do to a password is not strengthen it. It’s remove it.
If someone put a pixel-perfect copy of your login page in front of your users tomorrow, how many of your logins would it be able to steal?
Every authentication flow that still ends in a typed password hands the attacker a reusable credential to aim at. Taking the password out takes that credential out of the attack.
Mirket extends passwordless access beyond web applications — into operating-system logins, server access, privilege elevation and privileged sessions.
Why passwords survive beyond the browser
- Passwordless often stops at the application Passkeys and modern authentication work well for web applications, while the workstation, the server and privileged access are handled by something else entirely.
- Operating systems authenticate their own way The Windows logon, the Linux authentication stack, SSH and privilege elevation don't inherit the passwordless experience a browser application uses.
- Some systems still expect a credential Legacy applications, servers and administrative interfaces still want a username and a password, however the organisation would prefer its people to work.
Mirket treats these as three different problems rather than pretending one mechanism fits every system. That distinction is the whole page.
Passwordless across every access path
Different systems authenticate people differently, so the way the password is removed differs too. What stays the same is the objective: keep a reusable password out of the user’s hands.
- Web applications FIDO2 · WebAuthn · passkeys. Phishing-resistant sign-in for web, SAML and OpenID Connect applications.
- Operating systems Windows · Linux · SSH ·
sudo. On Linux the password step is bypassed outright. On Windows it is typed once, then held encrypted and bound to that machine so the user never types it again. - Privileged access PAM · RDP · web consoles. The target system keeps its password. Mirket holds it and injects it, so the user never sees it.
The three are not the same mechanism, and it is worth being precise about which is which:
| Access path | What removes the password | Where the password ends up |
|---|---|---|
| Web applications | A cryptographic credential bound to your domain | Gone from the authentication flow entirely |
| Windows logon | The agent supplies the credential; the user answers the second factor | Typed once at the first sign-in, then held on that machine — encrypted, and unreadable anywhere else |
Linux, SSH and sudo | The password step is bypassed in the authentication stack | Nowhere. There is no stored credential behind it |
| Privileged access | PAM retrieves the managed credential and injects it | Still held by the target system — and by Mirket, never by the user |
Phishing-resistant authentication for the web
For web and federated applications, Mirket uses FIDO2 and WebAuthn, backed by the reader already in the laptop, a passkey the user carries across their devices, or a separate security key.
- Passkeys A credential that syncs across the user's own devices — nothing reusable to type.
- Platform authenticators The fingerprint or face reader already in the laptop unlocks the credential locally.
- Hardware security keys A FIDO2 key for the populations that need a portable, separate authenticator.
What makes this phishing-resistant is not that the password is missing — it is that the credential is cryptographically bound to the real service. A lookalike site can present a perfect copy of your sign-in page and still get nothing, because there is no shared secret for the user to hand over and nothing for the attacker to replay.
This binding is specific to FIDO2 and WebAuthn. It is the reason this page separates them from the other two paths rather than filing everything under one word.
Passwordless shouldn’t stop at the browser
A passwordless programme is half-finished if people stop typing passwords into SaaS applications but still type one every time they open a workstation, reach a server or raise their privileges.
- Windows logon After the first sign-in on that machine, the user answers only the second factor. Windows still wants a password, so Mirket supplies it — see below for exactly how it is held.
- Linux logon The password step is bypassed in the authentication stack. Nothing is stored, because nothing is needed.
- SSH A shell opens on a Mirket method alone — no password is requested and none is kept.
- sudo Raising privileges is answered with Mirket authentication. The standing administrative password is not requested at all.
So the passwordless experience follows the person past the application and into the operating system itself. How the enforcement works at that layer — and what happens when the machine is offline — is on Operating System Logon MFA.
What happens to the Windows password
Windows is the one path where the password does not disappear — it moves. The user types it once, at their first sign-in on that machine. After that Windows still expects a password to open the session, so Mirket supplies it and the person is asked only for the second factor.
That makes how the credential is held the whole question, so here is the answer in full.
| Never in plaintext | Not in a file, not in the registry, not in a log |
| AES-256-GCM | Authenticated encryption, so tampering is detected and altered data is refused. A fresh random nonce each time means the same password never produces the same ciphertext twice |
| A key unique to that machine | Generated by the operating system’s own random number generator. There is no embedded, fixed or shared key in the product |
| The key is itself sealed | Held under Windows DPAPI at LOCAL_MACHINE scope, so the key is never written down in the clear either |
| Bound to the machine that created it | DPAPI’s machine key belongs to that Windows installation and cannot be exported. Copy the registry, the disk or a backup to another computer and the unseal fails |
| The username is hidden too | The registry value is named with an HMAC-SHA256 digest rather than the account name |
| Cleared after use | The key is wiped from memory as soon as it has been used |
What this is built against is data leaving the machine — a stolen disk, a copied registry hive, a backup, a cloned virtual machine. In every one of those the encrypted password is inert, because the key cannot be reconstructed anywhere else. Decryption is possible only on the machine the credential belongs to, which is the machine it signs into anyway.
The building blocks are the operating system’s own: AES-256-GCM (NIST SP 800-38D, FIPS 197), HMAC-SHA256 (FIPS 198-1), Windows CNG and Windows DPAPI.
On Linux there is nothing to protect, because nothing is kept. The password step is bypassed in the authentication stack, so a passwordless Linux logon, SSH session or sudo has no stored credential behind it at all.
Passwordless access to systems that still require passwords
Not every system can become passwordless. The user still can.
Legacy applications, servers and administrative interfaces may have no way to stop asking for a username and a password. That is usually where a passwordless programme stalls — the modern estate converts, and the older half sits outside it holding credentials that people have to know.
Mirket PAM resolves it from the other direction: the system keeps its password, and the user stops having one.
- RDP sessions A privileged RDP session opens already authenticated. Mirket retrieves the managed credential from the vault and injects it — the administrator never sees the target account's password.
- Administrative web interfaces The firewall console, the hypervisor, the backup system: the same injection, so the credential is used without being revealed.
⚙ Worth being precise about the mechanism. PAM credential injection is not FIDO2 or WebAuthn passwordless authentication. The target system still authenticates with a password; what changes is who holds it. Mirket manages that credential under privileged access control, rotates it, and puts it into the authorised session — so from the user’s side there is no password known, no password typed, and nothing to write down or pass on.
The target system can keep its password. The user doesn’t have to.
Choose the method that fits the access path
Mirket doesn’t force a browser mechanism into a logon screen where it doesn’t belong. The method follows the surface.
In the browser — web, SAML and OpenID Connect:
- FIDO2 / WebAuthn Phishing-resistant, bound to your domain
- Passkeys Synced across the user's own devices
- Platform authenticator The reader already in the laptop
- Security key A separate, portable FIDO2 authenticator
At the operating system — Windows, Linux, SSH and sudo:
- Push approval One tap on the enrolled phone
- Mirket Token A rotating code, verified on the machine
- Mirket OTP A single-use code from the app
FIDO2 and WebAuthn are not part of the operating-system list, and that is deliberate rather than a gap: at a logon screen the authenticator belongs to the operating system, so Mirket applies the methods that work there instead of claiming one that doesn’t.
One platform across every access path
MFA, single sign-on, passwordless and privileged access run on the same Mirket platform, so the browser sign-in, the operating-system logon and the privileged session are administered from the same console, over the same users, into the same audit trail. The mechanism changes with the access path; the visibility doesn’t.
That matters in practice because a passwordless programme is rarely uniform. A group can be passwordless in the browser, passwordless at the Windows logon, and reaching a legacy server through PAM — each under its own rule, and all in one audit trail.
Move to passwordless at your own pace
Passwordless doesn’t have to be an all-or-nothing migration. It is a policy per user and per group, so populations move when they’re ready.
| Pilot group | Fully passwordless, on the surfaces that suit them first |
| Privileged users | Passwordless where the flow allows it, PAM-controlled access where the target still needs a credential |
| Everyone else | Password plus a second factor, unchanged, until their turn |
Widen the policy as each population and each access path is ready. Nothing has to be switched over in one night, and nothing has to wait for the last legacy system to be replaced.
Passwordless on-premise or as a service
| On-premise | The authentication policy, the directory integration and the enrolment records all sit on your own servers |
| As a service | Mirket provides the identity and policy layer, while endpoint and directory-side components keep enforcing authentication where they need to be — inside your network |
Passwordless is not tied to a cloud-only deployment model. Which platform you run doesn’t change which access paths can lose the password. The architecture behind both is on Deployment.
What changes with Mirket
| Before | With Mirket |
|---|---|
| Users type reusable passwords into web applications | Web, SAML and OIDC sign-ins use FIDO2, WebAuthn or a passkey |
| Passwordless ends at the browser | Windows, Linux, SSH and sudo can lose the password too |
| A password reused from a breach still opens a work login | There is no reusable password in the flow to match |
| Privileged users know the target system’s password | PAM holds and injects it; the user never sees it |
| Legacy systems block the whole passwordless programme | They keep their password — the user still stops having one |
| Going passwordless means a single cutover | Policy is applied per user and per group |
| Passwordless assumes a cloud deployment | On-premise and as a service, the same |
Frequently asked questions
What is passwordless authentication?
Signing in without entering a password. The user proves who they are another way — a cryptographic credential held by the device, or an approval on a phone they have already enrolled. Which method applies depends on the application, the operating system or the access path.
Is passwordless authentication the same as MFA?
No. MFA describes authenticating with more than one factor; passwordless describes a flow where no password is entered. A flow can be both — a FIDO2 credential unlocked by a fingerprint is passwordless and multi-factor at the same time.
Is all passwordless authentication phishing-resistant?
No, and the two terms are not interchangeable. FIDO2 and WebAuthn are designed to be phishing-resistant — the credential only answers to the domain it was registered on, so a convincing fake page collects nothing worth replaying. Other passwordless methods remove the password without providing that binding. It is worth knowing which one is protecting which login.
Does Mirket support FIDO2 and WebAuthn?
Yes, for web, SAML and OpenID Connect sign-ins. The authenticator can be the reader built into the laptop, a passkey that syncs across the user's devices, or a separate hardware key.
Does Mirket support passkeys?
Yes. A passkey is a FIDO2 credential that syncs across a user's devices, so it works in the same flows as a platform authenticator or a hardware key.
Can Windows login be passwordless?
Yes. The user signs in once with their password on that machine; from then on they are asked only for the second factor — an approval on the enrolled phone, or a code from the app. Windows itself still expects a password, so Mirket supplies it, and how that credential is protected is set out above.
Can Linux and SSH access be passwordless?
Yes, and on Linux it goes further than on Windows: the password step is bypassed in the authentication stack, so there is no stored credential behind the logon, the SSH session or sudo at all.
Can sudo be passwordless?
Yes. sudo can be answered with a Mirket method rather than the standing administrative password, so raising privileges doesn't mean typing a password that several people know.
Can PAM provide passwordless privileged access?
Yes, and it works differently from the flows above. The target system may still authenticate with a password, but Mirket PAM holds that credential and injects it into the authorised session — so the user opens an RDP session or an administrative web interface without knowing, seeing or typing it.
What happens if a user loses the enrolled phone?
If the old handset is still to hand, one scan of a backup QR carries every account across to the replacement. If it has genuinely gone, the user re-enrols by whichever route you've set up: an expiring link to their mailbox, personal security questions, a link issued by an administrator, or two of those together. Mirket leaves that choice open rather than fixing one flow, because a treasury team and a seasonal warehouse intake do not deserve the same answer. Secure Self-Service covers it.
Does Windows still keep the password somewhere?
Yes, and it is worth knowing exactly how. Windows requires a password to open a session, so the credential is retained on that machine — never in plaintext, encrypted with AES-256-GCM under a key generated uniquely for that machine, with the key itself sealed by Windows DPAPI at LOCAL_MACHINE scope. DPAPI-sealed data can only be unsealed on the machine that sealed it, so a copied registry, a stolen disk or a restored backup yields nothing. On Linux the question does not arise: the password step is bypassed and nothing is stored.
Can Mirket run passwordless authentication on-premise?
Yes. Passwordless is part of the platform on either deployment — it is not tied to a cloud-only model. The architecture is on Deployment.
Can we migrate users gradually?
Yes. Enabling passwordless is a rule written against users and groups, so a pilot population can go first while everyone else carries on with a password and a second factor. Nothing has to be switched over in one night.
Related
Solutions — Operating System Logon MFA · On-Premise SSO · Privileged Remote Access · MFA for Legacy Applications
Products — Multi-Factor Authentication · Single Sign-On · Privileged Access Management
Industries — Education · Healthcare