MFA shouldn’t stop at the application
An MFA rollout has a natural shape. Federated applications first, because they redirect to an identity provider and the second factor slots in cleanly. Then the VPN, if the product does RADIUS. Then it stops.
What’s left outside is the set of logins that never leave the machine — and they are not minor logins. They are the console of the domain controller, the shell on the database server, and the elevation that turns an ordinary account into a local administrator.
Everywhere else, a stolen password meets a second factor. At the server console it meets the desktop.
And a server password travels. It’s typed on an administrator’s own workstation, saved in an RDP client, kept in a runbook, shared during an incident. Any copy is enough to open the console — because the console asks for nothing else.
If an attacker had a domain administrator’s password right now, how many of your servers could they open a console or an RDP session on before anything asked them for a second factor?
Why the operating system login stays on one factor
| Logon happens locally | Traditional federation does not sit inside the operating system’s authentication path. Windows, macOS and Linux check a local or domain credential themselves, and there is no native second-factor step to configure |
| Endpoints go offline | The control has to keep working with no network connectivity. If MFA fails at an airport, it gets removed within a week — so it often isn’t deployed at all |
| Privilege changes inside the session | Protecting the initial sign-in is not enough if UAC, runas or sudo can still elevate the session on a password that was already typed once today |
How Mirket protects the operating system login
Mirket doesn’t put MFA in front of the server. It puts MFA into the operating system’s own authentication path, so the credential is still checked by the operating system and the second factor is part of the same step.
- Windows logon & RDP Console sign-in, remote sign-in, workstation unlock and CredUI prompts — local, domain and remote.
- Linux SSH & console A second factor on SSH and console logins, with agents for Ubuntu, RedHat, RedHat-CentrifyDC, Debian and SUSE.
- macOS logon & unlock The same authentication policies extended to macOS login and unlock.
- Privilege elevation UAC,
runasand an administrative shell on Windows;sudoandsuon Linux.
Protect the moment privilege increases
The account somebody takes over first is almost never the account they came for. A phished password, a credential found in a script, a session on a machine somebody left unlocked — what any of those opens is an ordinary user’s world. Everything that follows depends on turning that into administrative rights, and on most estates the step that does it is the one nobody guards.
Elevation isn’t a setting. It’s the step every intrusion has to take.
Which is why protecting the sign-in and stopping there leaves the important half undone. A user passing MFA at the logon screen does not mean every elevation for the rest of that session should be trusted — and an attacker who never touched the logon screen at all is exactly the person the elevation prompt is standing in front of.
| Windows | UAC · runas · opening an administrative shell |
| Linux | su · sudo |
The challenge that has to be answered by a person
Mirket requires authentication again at that moment, so elevating is a decision in its own right rather than a re-use of the password typed at sign-in.
The consequence is worth stating plainly, because it is the whole argument for the control: a stolen password stops being a path to administrator and becomes only a way in. Somebody who has the credential and has reached a session still has to clear a factor they do not hold — on a phone they do not have — before that session becomes an administrative one. The rights they came for stay one step out of reach, and that step asks a human being.
And elevation stops being invisible
There is a second effect, and it is the one most teams don’t expect until they see it.
A prompt that asks for nothing produces nothing. Left alone, elevation is an internal operation of the host — it happens, it succeeds, and there is no moment in it where anybody is required to prove anything, so there is nothing for a reviewer to come back to later.
The second factor is what makes the machine ask. And a question somebody has to answer is a thing that can be recorded: who, on which machine, reaching for which account, when, and whether they got there.
- A record, wherever you run Mirket Elevation joins the authentication paths you already keep — logged with the account, the source address and the result, held in the audit trail and forwarded to your SIEM over syslog like everything else. On-premise and as a service alike.
- A signal, where you also run ITDR On its own, one refused elevation is a line somebody has to notice. Account takeover detection scores it against what else that identity has been doing and maps it to the MITRE ATT&CK technique it represents, so it arrives as part of a story rather than as an entry to triage. ITDR is available as a service.
Worth being precise about which part is which. The challenge at the elevation prompt, and the record it produces, are part of the MFA module and run wherever Mirket runs — on your own servers or as a service. The scoring and attack-chain correlation belong to Mirket ITDR, which is a service offering. The detection depends on the control: an environment that doesn’t challenge elevation has nothing to detect, because nothing about it was ever an event.
MFA even when the endpoint is offline
No internet connection does not have to mean no MFA. This is the requirement that decides whether an endpoint control survives contact with reality, because a control that fails at an airport is a control that gets uninstalled.
After activation, the endpoint verifies the second factor itself — no call to Mirket is needed at the moment of logon.
- Mirket Token The app produces a new code every 30 seconds; the machine checks it without calling Mirket.
- TOTP A third-party authenticator code, verified the same way.
- Recovery codes Reissued every day, so yesterday's list is already worthless.
Enabling it takes a single connected sign-in on that machine first. From then on it authenticates without connectivity — which is what makes this workable for travelling laptops, isolated servers and environments where continuous connectivity can’t be assumed.
One honest caveat, because it causes real support calls: the codes are derived from the clock, so a machine whose time has drifted badly will fail the check.
Built into the authentication path
Enforcement is integrated into the operating system’s authentication path rather than relying on a separate user-space process to decide whether a login should continue. That matters for a specific reason: if a local administrator can stop a background service and then sign in unchallenged, the control is optional.
| Windows | A credential provider — part of the logon flow itself |
| Linux | A PAM module, loaded where the system already evaluates pam_unix |
And removal is protected: uninstalling requires a removal code, so becoming local administrator is not enough to strip the agent off a machine.
Authentication methods for operating system access
These are the methods that apply at an operating-system logon screen — a different set from a browser sign-in, which is where FIDO2 and WebAuthn belong.
- Push notification Approve or deny on the phone
- Mirket Token A 30-second code, checked on the machine
- Mirket OTP Single-use code in the app
- TOTP Any RFC 6238 authenticator
- SMS Your own gateway, or ours
- Recovery codes Reissued every day, checked locally
- Passwordless No password typed at the console
Which method applies is set separately for each population — and for each of SSH, RDP and console logon, so the shell can carry a different method from the desktop.
Deploy it where your operating systems live
| On-premise | Run Mirket MFA inside your own environment, with authentication policy and directory integration kept on-premise. Protect Windows, Linux and macOS logins without moving your identity infrastructure to the cloud |
| As a service | Use Mirket as a service while endpoint enforcement remains at the operating-system authentication layer. For Active Directory and LDAP environments, directory credential verification stays inside your network through the Mirket Gateway |
The same operating-system protection is available whether Mirket is deployed on-premise or as a service. You aren’t choosing a reduced on-premise edition, and you aren’t getting a different endpoint agent for the cloud. The architecture behind both is on Deployment.
Set the scope separately for each flow
A rollout that has to be all-or-nothing doesn’t start. The controls are separable, so it can:
| By action | Logon · unlock · elevation — each on its own |
| By location | None, local only, remote only, or both |
| By population | Rules are written against users and groups, so one team can go first |
| By exception | Bypasses can be set globally, for accounts Mirket doesn’t know, for listed addresses and for named people — so a phased rollout always has a way back |
A common first step is remote-only enforcement on the servers that matter most, then widening to console and elevation once the pattern is understood.
Rolling it out across the estate
Hundreds of machines means unattended installation, not a technician at each console. The agent deploys silently through GPO, SCCM or any software distribution tool already managing the estate.
When the password can go entirely
For the populations it suits, the password can come out of the daily experience entirely. At the Linux logon, over SSH and at sudo no password is requested at all — nothing to type, and nothing retained afterwards. At the Windows logon the user signs in with their password once on that machine and answers only the Mirket prompt from then on; Windows still expects a credential, so Mirket holds it encrypted and bound to that machine. Passwordless Authentication sets out how it is protected.
It’s a policy per user and per group, so one team can drop the password while the rest carry on with a password and a factor.
What changes
| Before | With Mirket |
|---|---|
| The server console opens on a password alone | It opens on a password and a second factor, or on a passwordless method |
| RDP checks the password and loads the desktop | The challenge comes before the desktop |
SSH and the sudo after it are one secret | Both can carry a second factor |
| Elevation to administrator re-uses a password | It’s a distinct challenge at the moment rights increase |
| A stolen password reaches administrative rights | It reaches a session, and then meets a factor the attacker doesn’t hold |
| Raising rights leaves nothing anyone reviews | Every elevation attempt is an authentication event, with actor, target account and outcome |
| MFA fails when the laptop is offline | The endpoint verifies the code itself |
| Endpoint MFA depends on a stoppable enforcement process | Enforcement is integrated into the authentication path and protected against unauthorised removal |
Frequently asked questions
Can I add MFA to Windows login?
Yes. Mirket can require a second factor for Windows console logon, remote sign-in, workstation unlock and CredUI prompts. The scope is selectable — none, local only, remote only, or both — so a rollout can start narrow and widen.
Does Mirket support MFA for RDP?
Yes. The prompt appears inside the Windows authentication flow, so it is answered before the desktop is handed over. RDP can be enabled on its own — a common first step is remote-only enforcement on the servers that matter most.
Can Mirket add MFA to Linux SSH?
Yes. A PAM module sits in the Linux authentication stack, so SSH and console logins carry a second factor. Agents are available for Ubuntu, RedHat, RedHat-CentrifyDC, Debian and SUSE.
Can Mirket protect sudo with MFA?
Yes. sudo and su can require an additional authentication step, so elevating inside an existing session is a separate decision rather than a re-use of the password already typed at sign-in.
Can Mirket protect UAC and Run as administrator?
Yes. Windows privilege elevation — the UAC prompt, runas and an administrative shell — can require a second factor at the moment rights increase, not only at sign-in.
Besides blocking it, what does protecting elevation give me?
A record of it. Raising rights is normally an internal operation of the machine that leaves nothing anyone outside that host would review. Once a second factor sits on it, each attempt carries an actor, a machine, the account being reached for, a time and an outcome — logged with the other authentication paths and forwarded to a SIEM over syslog, on-premise or as a service. Where Mirket ITDR is also running, as a service, those events are scored as part of an attack chain rather than read one at a time.
Does MFA work when the computer is offline?
Yes. Offline, the second factor is a code the endpoint verifies itself — Mirket Token or TOTP, generated on the phone and checked on the machine — with daily recovery codes as the fallback. Enabling it takes a single connected sign-in on that machine first. The codes are derived from the clock, so a machine whose time has drifted badly will fail the check.
Does Mirket support macOS login MFA?
Yes. A macOS agent applies the second factor at login and unlock, alongside the Windows and Linux agents and under the same authentication policies.
Can operating system login be passwordless?
Yes, and it works differently on the two platforms. On Linux the PAM module lets the logon, SSH and sudo through with no password at all — none is asked for, and none is retained afterwards. On Windows the user signs in with their password once on that machine; after that they answer only the Mirket method, and the credential is held encrypted and bound to that machine. Passwordless Authentication sets out exactly how.
Can a local administrator remove the agent?
Not on local rights alone. Uninstalling requires a removal code, so an account that becomes local administrator cannot simply strip the control off the machine.
How is the agent deployed across a large estate?
Unattended, through GPO, SCCM or any software distribution tool already managing the estate. There is no per-machine console visit.
Can Mirket run on-premise for operating system MFA?
Yes. The same operating-system protection is available whether Mirket is deployed on-premise or as a service. On-premise, authentication policy and directory integration stay inside your environment; as a service, directory credential verification still happens inside your network through the Mirket Gateway. The detail is on Deployment.
Related
Solutions — VPN & Firewall MFA · Passwordless Authentication · Adaptive Authentication · RDP & SSH Session Recording
Product — Multi-Factor Authentication
Industries — Healthcare · Retail