Phishing-Resistant MFA Stalls on the Applications That Can't Support It

The identity dashboard shows that ten thousand employees have registered a hardware security key. The steering committee marks the phishing-resistant MFA rollout as complete. The help desk, however, is still resetting passwords for the payroll portal, and the database administrators are still typing credentials into a thick client. Enrollment is a project. Authentication is a posture. The two metrics rarely align.

The first deliverable of a modern authentication program is not a rollout plan. It is a list of every place a password is still accepted. The unit of work is the sign-in path, not the employee. A single application might have four distinct authentication paths: SAML for the web user interface, an LDAP simple bind for the API, a local administrator account for the console, and a service account for the backend connector. Marking the application as migrated because the web interface now uses the corporate identity provider leaves three password paths open. Pull the logs from the RADIUS servers, the directory binds, and the web proxies. Group them by client string and authentication source. The client string tells you more than the application owner will.

Every enterprise has a handful of applications that authenticate against a directory with a basic bind and a login form drawn in 2009. There is a network firewall cluster deployed six years ago that expects a username, a password, a comma, and a six-digit token. There is a mainframe front end where the terminal emulator asks for a user ID and password, and the user has a FIDO2 key in their pocket that the emulator will never ask for. You cannot solve a software architecture problem with a piece of plastic on a keychain.

You do not fix the application. You fix the path to the application. The application can keep its password field. The user just never types into it. Put an identity-aware proxy in front of the HTTP traffic, or a privileged access management bastion in front of RDP and SSH. The user authenticates to the proxy with a hardware key. The proxy terminates the session, looks up the legacy credentials in a vault, and injects them into the headers or passes them to the backend. The backend sees a service credential. The human sees a key. The password did not disappear. It moved into a vault. That vault is now the new crown jewel, and credential rotation is your problem.

This translation layer has limits. Some applications check the client IP or MAC address, which the proxy obscures. Some use client-side cryptography that the proxy cannot terminate. If the application’s native password-change interface is left active, a user can change the backend password and break the vault’s rotation. If the user authenticates to the proxy with a key, but receives a 30-day session cookie that is not bound to the device, an adversary-in-the-middle kit can steal the session cookie after the initial login. Phishing-resistant authentication without session binding is a front door with no back wall.

FIDO2 and passkeys are built on the assumption of a one-to-one binding between a human and a device. That assumption breaks on the manufacturing floor. At shift change, twelve people might use a single terminal logged in as a generic shift account. There is no per-person session to attach a phishing-resistant factor to. In a packaging plant, a supervisor might tape a security key to the back of a SCADA monitor so operators can tap the gold contact when the screen locks. A shared account cannot have a per-person phishing-resistant factor that means anything. The fix requires changing the account model to support fast user switching with per-user PINs, or wrapping the shared session in a broker that demands individual authentication before granting access. The first is a massive operational project. The second is a lease.

To keep legacy applications running during the transition, IT often leaves TOTP or SMS enabled as an alternative authentication method. A fallback to a six-digit code means the organization is not phishing resistant. It just added a new piece of hardware to a phishable process. Attackers will ignore the hardware keys and phish the SMS codes. If the help desk runbook includes a line that says to issue a temporary password when a user loses their key, the program is optional. The recovery flow is the real attack surface. If possession of a key can be replaced by a phone call and an SMS code, the recovery process needs its own strict authority limits.

Security can mandate the standard. It cannot fund the application upgrade. A mandate without a remediation budget produces exception forms, not code changes. The exception register is the real roadmap. Read it and you know where the program actually is. If the register has no owners and no expiry dates, it is not a program. Every exception needs an application owner, a business use case, a fallback method, and a review date. “Vendor does not support it” describes the obstacle, not the decision. The decision is whether to isolate the system, limit its users, or formally accept the exposure. An indefinite exception is a decommission. If you cannot name the person who gets paged when the exception fails, the exception is unowned.

The problem extends to vendor portals. An accounting department might use passkeys for the corporate identity provider while maintaining separate passwords for three tax portals. Because the vendor portal only supports SMS, and multiple clerks need access, there is a shared smartphone plugged into a wall charger in the controller’s office. The burner phone in the accounting desk drawer is the load-bearing pillar of the procurement process. You cannot ship the supplier’s authentication upgrade. Your leverage is the contract renewal. Put the federation requirement in the security addendum, reduce the number of accounts, and remove access promptly when roles change. Do not record the portal as protected merely because corporate email is.

The first eighty percent of a rollout creates the illusion of completion. The remaining twenty percent is where the actual architecture work happens. The program finishes when the last password path is closed, or when the business formally accepts the risk of the ones that remain.