M-22-09 made the login phishing-proof and moved the weak point to enrollment and recovery

The week

On January 26, 2022, the White House’s budget office formally told federal agencies to stop treating their networks as castles, with a strong wall around the agency network and trust for anyone inside it. For years that had been the standard model of government cybersecurity.

The memo

That day, the Office of Management and Budget issued memorandum M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles. OMB sets management policy for federal agencies, so its memos carry real weight. “Zero trust” is the idea that no person or device should be trusted just because it is on the right network; every request to use a system should be checked on its own merits.

The memo set specific goals for agencies to meet by the end of fiscal year 2024, organized around the pillars of CISA’s zero trust maturity model: identity, devices, networks, applications and workloads, and data. CISA is the federal agency that leads civilian cybersecurity. Agencies had 30 days to name a zero trust implementation lead, and 60 days to submit an implementation plan for fiscal 2022 to 2024 with a budget estimate. They were told to fund early work from existing budgets or from sources such as the Technology Modernization Fund.

What it required for logins

The headline requirement concerned logins. Agencies had to run centralized identity systems that applications could plug into. Agency staff, contractors and partners were to use enterprise-managed identities and phishing-resistant multifactor authentication. Multifactor authentication means proving who you are with more than a password, such as a code or a physical key. “Phishing-resistant” means a version that cannot be tricked out of a user by a fake website.

The memo named two: the federal PIV smart card, the chip-bearing ID card many federal employees already carry, and the WebAuthn standard, which lets security keys and phones prove identity to websites. For routine self-service access by staff, contractors and partners, agency systems were to stop supporting methods that fail to resist phishing. Those included text-message and voice codes, one-time codes and push notifications.

Public-facing systems that supported multifactor authentication had a year to offer a phishing-resistant option too. The memo acknowledged that some members of the public lack up-to-date devices, so for them it was an option rather than a requirement. It also told agencies not to ask the public for the make or model of their security keys.

When deciding whether to grant access, agencies were to consider at least one signal about the device alongside the user’s identity. The memo also addressed recovery, in a single paragraph. It said account recovery is by nature a potential bypass of normal authentication, and that recovery should rely on high-friction methods such as in-person checks or live video.

The rest of the package

There was more. Agencies were to keep complete device inventories through CISA’s Continuous Diagnostics and Mitigation program and deploy endpoint detection and response tools. They were to encrypt DNS and web traffic, including traffic that never left their own networks. DNS is the service that turns a name like a website address into a numerical location, and its lookups had often traveled unencrypted.

Within a year, each agency was to pick at least one internal application of moderate sensitivity that was not yet reachable from the internet. It then had to make that application fully usable over the internet, protected by identity rather than network location. Agencies also had to welcome vulnerability reports from the public and test their applications with outside experts. The memo told agencies to drop password rules requiring special characters or regular rotation within a year, rules long known to push people toward predictable passwords.

The context that week

M-22-09 followed the May 2021 executive order on improving the nation’s cybersecurity. It turned that order’s broad direction into deadlines and a shared definition of success.

The same week brought a related change to the card itself. On January 24, the National Institute of Standards and Technology published FIPS 201-3, the revised standard for PIV credentials. It updated the rules for identity proofing and for derived PIV credentials, which carry PIV-equivalent credentials on devices other than the card.

Identity proofing for the public was also in the news. The Internal Revenue Service faced sharp criticism that winter over a plan to require taxpayers creating online accounts to verify their identity through a private vendor using facial recognition. In early February, it said it would move away from that requirement. The episode showed how contested the moment of enrollment can be, even before the login itself is considered.

Most multifactor authentication in 2022 used one-time codes by text or app, or push approvals. Those methods stop password reuse, but an attacker running a convincing fake login page can relay the code in real time, and a user flooded with push prompts may approve one. M-22-09 required methods that bind the login to the genuine site, so a fake page gets nothing it can use.

That closed the most common route into agency accounts. It also changed where a determined attacker would push next. If the login cannot be phished, the attacker targets the moments when a credential is created, replaced or reset. Three of those moments matter most: issuing the authenticator, recovering a lost one, and the applications that cannot yet accept it.

The sections below take the mechanism first, in two parts: why a fake login page gets nothing, and how zero trust works on an ordinary morning. The three moments follow in order. After them come a bureau’s review six months after declaring success and what the gap costs. The last two sections cover the traits of stronger programs and the questions to ask about who can issue a new key.

Why a fake login page gets nothing

Start with why ordinary multifactor authentication can fail. Suppose an employee receives an email that looks like it comes from the agency’s IT team, asking them to sign in. The link leads to a fake page that looks exactly like the real one. The employee types a password; the attacker’s software instantly passes it to the real site. The real site sends a six-digit code to the employee’s phone; the employee, still believing the fake page is genuine, types it in; the attacker passes that along too. Within seconds the attacker is logged in. The second factor worked as designed. It protected the wrong conversation.

Push approvals have a different weakness. The user’s phone pops up “Approve sign-in?” and they tap yes. An attacker who already has the password can trigger dozens of these prompts, often late at night, until a tired or confused user taps yes to make them stop. Security teams call this prompt bombing or MFA fatigue.

The memo was blunt about the scale of the problem. It noted that such phishing attacks can be fully automated and run cheaply at scale. A tool kit that relays passwords and codes through a fake page can be pointed at thousands of users at once. Defenses that depend on each user spotting the fake will fail for some of them.

The cryptographic handshake

Phishing-resistant methods close both gaps by changing what the user does. Instead of reading a code and typing it, the user’s device performs a cryptographic exchange with the website, a mathematical handshake built on a secret that never leaves the card, key or phone. The device also checks the website’s identity as part of that handshake. A fake site at a look-alike address simply gets no valid answer. The user can be fooled; the device cannot.

The mechanics are worth a short explanation. When a user registers a security key with a site, the key creates a new pair of mathematical keys for that site alone. One half, the public key, goes to the site. The other half, the private key, stays inside the device. At each login, the site sends a random challenge. The device signs it with the private key, and includes the web address it is talking to. A fake site receives a signature bound to the wrong address, which the real site will reject.

The PIV card does this with a chip and a card reader. WebAuthn does it with a small USB or wireless security key, or with the secure hardware built into modern phones and laptops, which the industry calls a platform authenticator. Since the memo, many people have met the same idea under the friendlier name “passkeys.” A code can be relayed by anyone who controls the connection between the user and the real site; a phishing-resistant credential answers only the site it was registered with, however convincing the impostor looks.

What it does not stop

The handshake protects the login. It does not protect everything that follows. After a successful login, the site issues a session token, a digital pass that keeps the user signed in. Malware on the user’s device can steal that token and replay it from elsewhere. A user can still be persuaded to approve a malicious application’s request for access to their mailbox. And the handshake says nothing about whether the person holding the key is the person it was issued to. Each of those gaps points to a moment outside the login itself.

How zero trust works on an ordinary morning

Consider what the memo asked for from the point of view of one employee. Under the old castle model, a staff member at headquarters logged into the network once, with a password, and was then trusted to reach most internal systems because they were “inside.” A remote worker connected through a VPN, a secure tunnel into the network, and from then on was treated the same way. The network location did most of the trusting.

Under zero trust, the employee opens a laptop at home or in the office, and the location makes little difference. They sign in to the identity provider with a PIV card, a security key or the laptop’s built-in authenticator. When they open the case management system, that system asks the identity provider to vouch for them. The request is checked against more than identity. The questions are whether the agency knows and manages this device, whether it is up to date, and whether this person’s role allows access to this application. Only then does the door open, and only to that application.

This is why the memo bundled requirements that might look unrelated. A complete device inventory lets the agency check whether a device asking for access is one it recognizes. Encrypting DNS and web traffic makes it harder for anyone watching the network to see or tamper with where users are going. Making an internal application reachable over the internet, protected by identity rather than location, proves the model works without the castle wall. And dropping forced password rotation and special-character rules reflects years of evidence about their effect. Those rules push people toward predictable patterns, such as a season and a year with a symbol tacked on, which helps nobody.

Where the trust moves

The effect for attackers is that stealing one password, or landing on one computer, no longer opens the whole estate. Each step requires passing another check. That is the promise.

The cost of the promise is concentration. In the castle model, trust was spread across the network. In the zero trust model, it rests on a few systems: the identity provider, the device management system and the processes that decide who holds which credential. The memo told agencies to consolidate authentication into as few identity systems as practicable, which strengthens monitoring but also creates a high-value target. An attacker who can enroll a key, reset a credential or slip through an application the identity provider does not cover gets the trust the system was built to grant. The checks can be gamed in three places.

Issuing the authenticator

A phishing-resistant credential is only as trustworthy as the process that put it in someone’s hands. For PIV cards, that process was mature: in-person identity proofing, background checks and controlled card issuance. “Identity proofing” means confirming that a person is who they claim to be, usually by checking documents, before giving them a credential.

The difficulty was coverage. Many people who touch agency systems do not hold PIV cards, including short-term contractors, some field staff, partners at state agencies and users of shared workstations. Others hold cards but use devices, such as phones and some cloud applications, where card readers do not work.

Security keys and platform authenticators based on WebAuthn filled those gaps. Each one needs an enrollment step that links the new authenticator to the right person. If enrollment means a user signs in with a password and a text code and then registers a key, the strong credential inherits the weakness of the weak one. An attacker who phished the old factors can enroll their own key and keep it.

Anchoring enrollment

Agencies that did this well tied enrollment to an existing strong credential, such as the PIV card, or to supervised proofing, in person or by video with document checks. They logged every enrollment and alerted the user through a separate channel when a new authenticator appeared on their account.

The bootstrap problem is real for new hires. On day one, a new employee has no strong credential to anchor to, and a PIV card may take days or weeks to arrive after background checks clear. Agencies handled this in different ways. Some issued a security key in person on the first day, after checking identity documents at the same desk. Some gave a short-lived temporary access pass, valid only for enrolling an authenticator, delivered through the hiring manager. The weak pattern was a password and a text code that stayed in place until the card came, sometimes for months.

Distribution as a supply chain

Distribution has a cost. Shipping keys to remote staff, keeping spares, tracking which serial number belongs to whom and handling returns at offboarding is logistics, not configuration. Agencies that budgeted for it as a supply chain moved faster than those that treated keys as an accessory.

The shipment itself is a risk. A key mailed to a home address can be intercepted or sent to an address an attacker has changed. Stronger programs shipped keys unregistered, required activation through a separate supervised step, and checked the serial number at activation against the one shipped. Keys that never activated were followed up rather than forgotten.

How enrollment differs by type of user

Different user populations needed different paths. Federal employees with PIV cards could anchor everything to the card. Contractors were harder. Some held PIV cards, others held only agency accounts, and their identity data often came from a contracting officer’s list rather than from HR. Partners at state and local agencies who used federal systems, for grants, benefits or law enforcement data, typically had no federal credential at all. The memo included contractors and partners in the requirement, but left agencies to decide which external users counted as partners.

The public was a separate case again. For people using public-facing services, the memo made phishing-resistant authentication an option, not a mandate. The IRS controversy that winter showed why. Strong identity proofing for the public raises questions of access, privacy and fairness that do not arise for employees. A process that works for a cleared federal worker at a badge office may exclude a retiree without a smartphone.

Who owns enrollment

Enrollment crosses several offices, which is why it often has no single owner. Personnel security and HR know who has been hired and cleared. The card office issues PIV credentials. The IT identity team runs the identity provider where security keys and platform authenticators are registered. For contractors, the contracting officer’s representative is often the only person who knows when someone starts or leaves.

A workable model gives each person a sponsor, the official who vouches that they need access. The sponsor’s confirmation is a precondition for any new authenticator, and the sponsor is notified when one is added. The same link drives offboarding. When a contract ends or an employee leaves, every authenticator registered to that person is revoked, and keys are collected or recorded as lost. Programs that tracked issuance carefully but treated revocation as an afterthought left valid credentials in the hands of people who no longer worked there.

Recovering a lost one

People lose keys, replace phones and forget PINs. Each event sends them to a help desk, which must decide quickly whether the caller is who they claim to be and then issue a temporary credential. That decision is now the softest point in the system. A help desk agent who resets a privileged user’s authentication on the strength of a confident voice and a few facts from a social media profile undoes the whole investment.

The technique has a name: social engineering, manipulating people rather than machines. It is old, cheap and effective, and it becomes more attractive precisely when the technology gets harder to beat.

The memo saw this coming. Its single paragraph on recovery called recovery a potential bypass and a significant threat vector, and asked for high-friction methods such as in-person verification or live video. It set no deadline or measure for that expectation, though, and it did not mention help desks or the contracts that govern them. The login requirement came with a date; the recovery expectation came with a sentence.

Controls that hold under pressure

Recovery procedures needed the same rigor as enrollment. Practical controls include:

• a callback to a number already on file, not one the caller provides;
• manager or sponsor confirmation;
• video verification against the photo on record for privileged accounts;
• a short, scoped temporary access pass rather than a reset to a password.

Privileged accounts, the ones with administrative power over systems, warrant a separate recovery path with more checks and a delay. Each recovery should generate an alert to the user and to security, since an unexpected reset is a strong signal of attack.

Some details matter more than they appear. Knowledge questions, such as a date of birth or the last four digits of a Social Security number, are weak because such data is widely exposed in breaches. A callback is only as good as the number on file, so changes to contact details need their own checks. A temporary access pass should expire quickly and be good only for registering a new authenticator, not for general sign-in.

The service trade-off

The trade-off is service time. Users locked out of their accounts cannot work, and help desks are measured on resolution speed. Agencies had to accept that recovery for high-risk accounts would take longer and to explain why. Issuing two authenticators at enrollment, so that losing one does not trigger recovery at all, reduced the volume.

Self-service recovery can help, if it is anchored correctly. A user who still holds one registered key can use it to register a replacement for the other without calling anyone. A user who has lost everything should face the full, slower path. The design aim is to make the easy route available only to people who can prove possession of something strong.

Recovery for the public

Public-facing services face the same problem at a larger scale and with fewer tools. A member of the public who loses the phone holding their passkey cannot be called back on a number on file or confirmed by a manager. Many services fall back to email or text-message codes for recovery, which reintroduces exactly the weakness the stronger login removed.

The pandemic years had shown how attackers exploit identity checks in public programs, with widely reported fraud against unemployment insurance and other benefits. A recovery path that a fraudster can complete with stolen personal data is an enrollment path for the fraudster. Stronger designs offer several routes of different strength. A user who still holds a second registered authenticator can recover alone. A user with nothing left goes through remote document and selfie checks, or in person at a local office. Accounts with high-value actions, such as changing where benefits are paid, get a waiting period and a notice to the old contact details.

When the help desk is a contractor

Many agencies outsource their help desk, sometimes to a contractor serving several agencies at once. The recovery procedure then lives in a statement of work and a script the agency may never have read. Contract terms should spell out the verification steps for each account tier, require recorded calls for privileged resets, and give the agency access to reset logs. A monthly sample of resets, checked against the procedure, shows whether the script is followed when the queue is long.

Performance measures need the same attention. A contract that pays for tickets closed within a target time rewards fast resets. Adding a measure for procedure compliance on sampled resets, with consequences when it falls short, balances the incentive. Agencies can also require that the contractor flag unusual patterns, such as several privileged resets in a short period or repeated calls about the same account.

The applications that cannot accept it

The third moment gets less attention. Phishing-resistant authentication works through an identity provider that applications trust. An identity provider is a central service that checks who you are once and then vouches for you to many applications, which is what makes single sign-on possible: one strong login, many systems.

Legacy applications with their own password databases, older protocols that send passwords directly, mainframe access and some commercial products could not be put behind modern single sign-on without changes. For those, agencies kept passwords and weaker factors alive, and attackers went looking for them.

The memo’s requirement to make at least one internal application available over the internet, protected only by identity and device checks, was a forcing function here. It made agencies prove, on one real system, that modern authentication could replace the network boundary. It also exposed how many applications were not ready.

Inventorying the ways in

A practical path was to inventory every authentication route into each high-value application, including service accounts, application programming interface keys and legacy protocols, and to close or wrap them one by one. A service account is a login used by software rather than a person, for example a nightly job that moves data between systems. An application programming interface, or API, is a doorway that lets one program talk to another, and an API key is the password for that doorway. Neither involves a human tapping a security key, so both are easy to overlook. An application with modern single sign-on at the front door and a basic-authentication interface at the back is still exposed.

Wrapping is the middle option between fixing and retiring. A legacy application can sometimes be placed behind a gateway that performs modern authentication first and passes the user through. Privileged access tools can broker administrator sessions to older systems without exposing their passwords. The memo allowed such tools as a stopgap for high-privilege systems that were hard to modernize. It warned against using them as a general substitute for multifactor authentication or for modernizing the system itself.

Session tokens and consent

Two further routes bypass the login without touching it. The first is the session token issued after a successful sign-in. If malware on a user’s device steals it, the attacker can act as the user until the token expires. Controls include shorter session lifetimes for sensitive applications, re-checking device health during a session, and binding tokens to the device where that is supported. Protecting the endpoint, through the detection and response tools the memo also required, matters as much as the authenticator.

The second is consent. Modern cloud platforms let users grant third-party applications access to their mail or files. A user who approves a malicious application has handed over access that no later login check will stop. Agencies can require administrator approval for new applications, review existing grants, and alert on applications that request broad permissions.

Non-human identities

Service accounts deserve their own program. They often hold broad permissions, rarely change their passwords and are owned by nobody in particular. A practical approach assigns each one a named human owner, limits what it can reach, and replaces stored passwords with managed credentials that rotate automatically or with short-lived tokens. Logging their activity separately makes unusual use easier to spot, since a service account that suddenly logs in interactively is a strong signal.

Test and administrative tenants

Cloud services added a less obvious side entrance. Agencies and their contractors often created test or development tenants, separate instances of a cloud service, that never received the production security settings. A forgotten test account without multifactor authentication can still have permissions that reach production. The inventory has to cover every tenant the agency owns, including ones nobody signs in to every day.

Six months after a bureau declared success

Take a hypothetical federal bureau that announces success: every employee now signs in with a PIV card or security key. Six months later, its security team reviews three things.

First, enrollment. They find that remote contractors registered their security keys after logging in with a password and a texted code. For most, that was harmless. But the log shows two keys registered from an unusual location at night, on accounts whose owners say they never did it. The strong system had a weak doorway.

Second, recovery. The bureau’s help desk is run by a contractor measured on how quickly it closes tickets. A sample of resets shows that agents often verified callers by asking for an employee ID and a manager’s name, both of which can be found or guessed. One reset was for a system administrator.

Third, applications. The bureau’s grants system is behind single sign-on, but an older reporting interface still accepts a username and password. A service account with broad access has a password that has not changed in years.

In none of these cases did the authenticator fail; in each, the process around it did. The fixes are unglamorous: enroll new keys only via an existing PIV card or a video check, rewrite the help desk script and audit it monthly, and close or wrap the back doors into the grants system.

What the review would report

The review also changes how the bureau measures progress. Its original metric, the share of users with a strong authenticator, read close to complete. The review adds three more. One is the share of enrollments anchored to a strong credential or supervised proofing. A second is the share of sampled resets that followed the procedure. The third is the number of authentication routes into high-value applications that still accept passwords. Each of the new numbers starts low, which is why they are worth measuring.

Security spending undone by process

For an agency head, a board member or a general counsel, the significance is that security spending can be undone by process. An organization can buy the strongest login technology available and still be breached by a phone call to the help desk.

The costs show up in several places. Authenticators must be bought, shipped, replaced and recovered. Help desks need more time and better scripts for high-risk resets, which can mean longer waits and frustrated staff. Contracts with outsourced providers need renegotiating. And legacy applications that cannot accept modern login need investment or retirement.

The risks are just as concrete. A compromised administrator account can expose sensitive records, disrupt services and trigger reporting obligations. Inspectors general and oversight committees will ask whether the agency adopted phishing-resistant authentication and also whether it could be bypassed. And the reputational damage of a breach that began with a help desk call is acute, because it looks avoidable.

How the stakes differ across government

The same gap plays out differently by type of organization. A large cabinet department with many components faces consolidation first. Its bureaus may run separate identity systems, help desks and contracts, so a strong process in one component does nothing for another. A small agency may rely on a shared service provider for identity or help desk support. Its recovery procedure is then written by someone else, and must be read and tested like any other contract.

Contractors and partners sit between those cases. The memo’s example of a partner was a government contractor submitting financial information, and it left agencies to define the rest of the category for their own systems. A contractor serving several agencies might face several enrollment processes, several kinds of authenticator and several help desks. Agencies that accepted each other’s strong credentials through federation reduced that burden. Those that did not pushed contractors toward the lowest common denominator, which tended to be a password and a code.

The Department of Defense runs its own zero trust strategy and its own common access card, so its path differs in detail. State and local agencies are not bound by OMB memos at all. Many still face federal security requirements tied to data they receive, such as the FBI’s CJIS Security Policy for criminal justice information and IRS Publication 1075 for federal tax information. For them, M-22-09 was a model to follow rather than a rule.

The counter-arguments

The first objection is that this focus is a distraction. Phishing-resistant authentication blocks the most common attacks at scale, while help desk social engineering takes effort and targets a few accounts. Agencies should finish the rollout before worrying about the edges.

That objection is right about order and wrong about timing. Rolling out strong authentication is the priority. But enrollment and recovery processes are designed during the rollout, not after it. An agency that enrolls keys using text codes in year one has already built the weakness. The cheapest moment to anchor enrollment is the first one.

The second objection is that high-friction recovery hurts the mission. Field staff, people working odd hours and those without easy access to a supervisor can be locked out for hours. That cost is real. Tiering answers most of it: the slow path applies to privileged accounts and to users who have lost every authenticator, not to everyone. Issuing two authenticators reduces the number of people who reach the slow path at all.

A third objection concerns the public. High-friction identity checks for citizens can exclude people without smartphones, current identity documents or broadband. The memo recognized this by making phishing-resistant authentication an option for the public. Public services need alternatives, such as in-person verification at a local office, that are strong without assuming every user has the latest device.

Traits of the stronger programs

Strong programs share a few traits:

• Enrollment anchored to strength: new authenticators are registered only through an existing strong credential or supervised identity proofing.
• Two authenticators per person, so a lost key is an inconvenience, not a help desk call.
• Tiered recovery, with privileged accounts on a slower, more careful path and an alert on every reset.
• Contracts that carry the controls, giving the agency the script, the recordings and the logs.
• An inventory of every way in to high-value applications, including service accounts, API keys, legacy protocols and test tenants.
• Logistics with an owner, covering keys, spares and returns.
• Measures beyond coverage, tracking anchored enrollments, procedure compliance on resets and remaining password routes.

Weak programs have their own pattern. Programs report the percentage of users with strong authenticators and stop there. Enrollment uses the very factors the program was meant to replace. Help desks are measured only on speed. Outsourced scripts go unread. And the inventory covers the front door of each application but not the side entrances.

Sequencing the work

The order of work matters. Anchoring enrollment comes first, because every later credential inherits its strength. Recovery tiers and help desk scripts come next, since attackers turn to them as soon as the login hardens. Issuing second authenticators lowers recovery volume and makes the stricter process affordable. Application inventory runs alongside, starting with the systems that hold the most sensitive data or grant the most privilege. Each step produces a measure that can be reported to leadership.

Who can issue a new key

• When someone registers a new security key or phone, what proves it is really them?
• If a caller tells the help desk they have lost their key, what exactly happens, and would it stop a confident impostor?
• Do privileged accounts follow a different, slower recovery path, and who is alerted when one is reset?
• Have we read the help desk script our contractor uses, and do we sample recorded resets against it?
• For our most important applications, what are all the ways in, including service accounts, API keys and older protocols?

With hindsight

The memo’s targets fell due at the end of fiscal 2024. Phishing-resistant methods have since become easier to deploy as passkey support spread across major operating systems and browsers. Technology that once required card readers or dedicated keys is now built into devices people already carry.

Standards caught up

Standards followed the technology. In October 2022, CISA published guidance urging organizations to adopt phishing-resistant multifactor authentication and explaining the options. In April 2024, NIST issued a supplement to its authentication guidelines addressing syncable authenticators, the kind of passkey that copies across a user’s devices through a cloud account. Syncing makes losing a device less disruptive. It also means the security of the passkey depends partly on the recovery process for that cloud account, which moves the recovery question rather than removing it.

NIST finalized its revised digital identity guidelines, SP 800-63-4, in July 2025. NIST is the federal standards body whose identity guidelines many agencies and companies follow. The revision covers identity proofing, authenticators and federation, so it shapes how enrollment and recovery are judged across sectors.

The Department of Defense set its own course. Its zero trust strategy, published in November 2022, set a target of fiscal 2027 for what it called target-level zero trust, a longer horizon than the civilian memo’s.

Enrollment under scrutiny

Identity proofing drew its own scrutiny. In March 2023, the General Services Administration’s inspector general reported that GSA had misled customer agencies about whether its Login.gov service met NIST’s requirements for remote identity proofing at the higher assurance level. The finding concerned the step before any login: how confident a service is that the person enrolling is who they claim to be.

Attackers moved as expected

The shift of attacker attention to enrollment and recovery played out in public. In September 2023, Caesars Entertainment disclosed in an SEC filing that attackers had reached its network through a social engineering attack on its outsourced IT support vendor. CISA’s advisory on the Scattered Spider group, last updated in July 2025, describes attackers posing as employees to get help desks to reset passwords and move multifactor authentication to devices they control. Those are the moments the memo addressed only briefly: not the login itself, but who gets to change it.

The side entrances were tested too. In January 2024, Microsoft disclosed that a Russian state-sponsored group had used password spraying against a legacy test account without multifactor authentication, and from there reached corporate email. CISA later issued an emergency directive requiring federal agencies to act on the agency correspondence exposed. The weakness was an account outside the protections everyone else had.

Session theft was tested in public too. In October 2023, Okta disclosed that an attacker had used a stolen credential to reach its customer support case management system. The attacker viewed files that some customers had uploaded for troubleshooting, which can contain session tokens. Several customers then reported attempts to use those tokens against their own systems. The login had not been phished. The attacker went around it, through a support process.

What held up

By this point in 2026, the better security reviews ask about the help desk in the same breath as the authenticator. M-22-09 named the login standard clearly and flagged recovery as a risk. The recovery process needed the same deadlines and measures as the login.

The underlying dynamic is simple. Attackers look for the cheapest way in. When the technical barrier rises, the cheapest way in becomes a person with the authority to make an exception, and the help desk exists precisely to make exceptions for people who are stuck.

Inside and outside government, the strength of any security system is set by its weakest legitimate process. When you invest in a stronger lock, ask in the same meeting who can issue a new key, how they verify the person asking, and who checks that they did. Those questions cost nothing to ask and often reveal where the real exposure lies.