Taking the laptop shouldn’t mean taking the keys.
Passkey-controlled disk unlock, Windows sign-in, and Active Directory authentication. Designed for physical-access threats, with authentication on your existing domain controllers.
Be part of what’s next ↗That belongs in the threat model.
A laptop left on a train puts the hardware in someone else’s hands. Encryption needs to account for an attacker who can open the case, probe components, and work offline.
Monban’s design goal is to require cryptographic input from a separate user-held authenticator, alongside the TPM, so compromising the laptop’s TPM alone is insufficient to unlock the disk in that mode.
Even BitLocker’s TPM + PIN mode still relies on the laptop’s TPM. On vulnerable implementations, extracting TPM secrets can bypass hardware rate limits and expose the PIN to offline guessing. Monban’s goal is a separate cryptographic dependency that stays with the user.
FIPS 140-2 level 2 provides tamper evidence. That alone does not guarantee resistance to physical key extraction.
Why adding a PIN is not the whole answer ↗A pre-boot PIN followed by a separate Windows sign-in adds friction. Monban’s goal is one passkey authentication before boot, carried securely through to the desktop and network access.
The case for pre-boot authentication ↗Bring passkey sign-in to Windows and on-premises Active Directory without moving authentication to a cloud identity provider. Your local domain remains the authority.
The native Windows gap ↗Authentication is designed to run on your domain controllers and use their replication and redundancy. There is no separate Monban appliance or vendor-hosted service in the login path.
Designed around existing AD availabilityA modular Rust suite. Device protection at the edge; authentication on your domain controllers.
monbase-prebootA Rust UEFI application for slot, TPM, and FIDO logic, with helpers for pre-boot provisioning.
monbase-loginA Rust Windows provider and broker/service for enrollment, consuming the pre-boot handoff, and supported authentication integration.
monbase-enterpriseA Rust issuer and integration layer on your AD domain controllers, with enrollment, replication, and revocation behavior.
Managing Windows fleets? Working with on-premises AD? Exploring passkeys before boot?
Interest registration for product updates and early-access news is coming soon.
Early access is not yet open.A pre-boot PIN does not turn the laptop’s TPM into a physically impregnable vault. In the BitLocker implementation studied by faulTPM, TPM compromise bypassed anti-hammering and left the PIN-derived encryption layer vulnerable to offline guessing. A strong enhanced PIN retains cryptographic protection; extracting TPM secrets does not automatically decrypt every TPM + PIN configuration. The demonstrated attack affected specific AMD firmware TPMs.
Microsoft: BitLocker countermeasures ↗Research: faulTPM, TPM + PIN analysis ↗FIPS 140-2 level 2 includes tamper-evidence requirements. It does not, by that rating alone, establish the stronger physical protection of higher levels or immunity to invasive key extraction. TPM assurance varies by model, certification, and physical-security rating. Monban’s design treats TPM compromise as a threat to address, rather than assuming a certification prevents it.
NIST: FIPS 140-2 physical security levels ↗NCSC recommends TPM + PIN for BitLocker. NIST SP 800-111 discusses pre-boot authentication and allows reuse of enterprise authentication when it provides multiple factors. Neither is a certification or endorsement of Monban. A single ceremony must preserve strong authentication and a secure handoff.
NCSC: Windows guidance ↗NCSC: why BitLocker PINs matter ↗NIST SP 800-111, §4.2 ↗Microsoft’s native FIDO2 security-key Windows sign-in documentation lists on-premises-only AD domain-joined devices as unsupported. Monban targets that deployment gap. This is not a claim that all passwordless Windows authentication requires Entra.
Microsoft: FIDO2 sign-in requirements ↗The intended online authentication path uses the organisation’s DCs, with no additional central vendor service. It still depends on the health of AD, DNS, the network, and deployed Monban components. Cached/offline behavior and revocation semantics will be documented with supported configurations.
Physical-access protection concerns a properly configured, powered-off or supported hibernated device. An already-unlocked running system and its in-memory keys require different protections. Authenticator choice and recovery mechanisms must preserve the same threat model. Protection against TPM extraction requires an external cryptographic secret, such as one derived by a supported PRF authenticator; merely checking a token and releasing a TPM-only secret does not provide that property.
Logo artwork, colour palette, typography, and ready-to-use product copy.
Interest registration is not available yet. The contact form is disabled and does not collect or submit personal details. This page uses no advertising trackers and sends no marketing emails. When registration opens, we will publish information about how your details are used and how to withdraw consent.