Skip to content

NeversKey

How it works

NeversKey restores administrative access to Windows machines when Entra ID is compromised or unavailable. It relies only on components already shipped with Windows: PKU2U and its built-in local identity provider, reached through Remote Desktop.

A customer-owned offline root is prepared in peacetime. During a crisis it issues a certificate valid a few hours, for a local break-glass account, and the administrator connects with mstsc /restrictedadmin.

Goals and non-goals

  • Regain interactive (Remote Desktop) administrator access to Entra joined or workgroup machines with no dependency on Entra ID, Intune, Active Directory or any network service.
  • Keep the trust anchor offline, recoverable from a printed QR code or Shamir shares.
  • Deployment and audit that work with Intune, a GPO or a plain PowerShell script.

Not in scope: replacing an enterprise PKI or Windows Hello for Business; machines that were wiped or whose NeversKey settings the attacker removed (the audit detects it, it cannot prevent it); the console logon.

The Windows mechanism: PKU2U and Local Cert Issuer

Windows has a built-in local identity provider for PKU2U, whose trusted roots are a machine certificate store, Local Cert Issuer, empty by default. A PKU2U logon is accepted when:

  • the certificate of the client chains to a root in the Local Cert Issuer store of the target, and its common name is an existing, enabled local account of the target;
  • the target presents a certificate of its own, whose chain ends in its own Local Cert Issuer and in the one of the workstation;
  • the local identity provider is enabled and PKU2U online identities are allowed on both sides.
What the workstation and the target need for a PKU2U crisis logon, and the two crossed checks

What follows from it:

  1. The root goes into Local Cert Issuer, not into the trusted roots: it is trusted only by the local identity provider, not for TLS or code signing.
  2. Every CA in Local Cert Issuer can issue logons for every enabled local account. Nothing else may go there: the audit treats any extra certificate as a finding.
  3. Every machine needs a certificate of its own. NeversKey makes it self-signed, without CA rights, and pins it in the machine's Local Cert Issuer: a pinned certificate without CA rights cannot issue logons. The root never comes out for it, and there is no machine list to keep: the workstation reads that certificate from the machine the first time it connects, as an SSH client learns a host key, and the administrator compares its thumbprint with the audit report.
  4. Every machine needs an enabled local account named as the crisis certificates: the built-in Administrator managed by Windows LAPS, or a dedicated account. Nobody needs to know its password.
  5. Remote Desktop in Restricted Admin mode reuses the PKU2U network logon: no password is delegated to the machine.

Lifecycle

  1. Init, offline ceremony: the root key is generated in memory and printed. The printed page alone restores the key and its certificate; the key is wiped from memory afterwards.
  2. Deploy: the settings (root in Local Cert Issuer, local identity provider, PKU2U online identities, Restricted Admin) and the machine certificate, by a script run once as SYSTEM, or a .reg for a GPO. Public data only.
  3. Audit, periodic: a read-only script on each machine, an HTML report of the machines that cannot be recovered and of any unexpected certificate.
  4. Crisis: the vault issues a NeversKey valid a few hours; the administrator adds the machine and connects.
  5. End of the crisis: the NeversKey is deleted and the changes of the workstation undone.

Threat model

The root key opens every enrolled machine: NeversKey is a deliberate, controlled back door. Its security is the protection of that key and the visibility of its use.

ThreatMitigation
Theft of the root key backupEncrypted with a passphrase, optional Shamir split among k of n custodians, generated and used on an offline machine only.
An attacker who controls Entra ID or Intune removes the NeversKey settingsCannot be prevented by design; the audit reports it. Deploy through a channel independent from Intune where possible.
Theft of a crisis USB keyValid a few hours (8 by default, 72 at most), key generated on the card. PKU2U has no PIN, so the key is a bearer token for that time, to be kept like a key to the server room. Emergency stop: disable the break-glass account.
Substitution of the request or the responseThe request code read out by phone is the fingerprint of the request; the response opens only on the requesting workstation and account, once.
Misuse by an insiderCeremonies need the passphrase or k custodians; every issuance is logged; every logon is a 4624 event (package Pku2u) for the SIEM.
A rogue CA added to Local Cert IssuerThe audit compares both physical stores with the expected thumbprints and flags any extra certificate.
Theft of the key of a machine certificateIt has no CA rights and cannot issue logons; it only lets its holder impersonate that machine, and that holder is SYSTEM there anyway.

No revocation server

The certificates carry no CRL or OCSP address: an unreachable one would make the logon fail during the crisis, exactly when the network may be isolated, and a CRL would bring the offline root online regularly. Revocation is replaced by a short validity for the crisis certificates and by the renewal of the machine certificates. NeversKey never contacts a vendor service.

Supported Windows versions

The crisis connection works from a Windows 11 administrator workstation to Entra joined Windows 10, Windows 11, Windows Server 2019, 2022 and 2025 machines; the machine stays Entra joined. Windows Server 2016 is not supported.

Background: PKU2U peer-to-peer authentication internals and RDP / mstsc PKU2U prerequisites.