Why a stolen DMV file weakened identity checks at agencies that were never breached

The week

Just before the third week of June 2023, Louisiana’s Office of Motor Vehicles and Oregon’s DMV disclosed that license and ID holder records had been taken through Progress Software’s MOVEit Transfer. MOVEit is a managed file transfer product: software organizations use to send large or sensitive files to partners securely, rather than as email attachments. Both states used it to move files between offices and partners. Neither had been singled out. They were two of hundreds of organizations caught in the same campaign.

Oregon’s transportation department announced its exposure on June 15. It put the number at about 3.5 million license and ID holders. It said attackers had copied files shared through MOVEit before Progress’s security alert reached it. It could not tell which individuals were in those files, so it advised anyone with an active Oregon license or ID to assume they were.

Louisiana’s warning came the same day, followed by a press conference on Friday, June 16. Casey Tingle, director of the Governor’s Office of Homeland Security and Emergency Preparedness, said more than six million records were involved, some of them duplicates because residents hold both a license and a registration. Officials said they believed everyone with a state-issued license, ID or vehicle registration was likely affected. According to state officials and press reports, the exposed fields included names, addresses, Social Security numbers, dates of birth, height, eye color and disability placard details.

For many state and local agencies, that meant the details printed on almost every driver’s license in their state, plus the Social Security numbers behind them, were now sitting on a criminal’s hard drive. They had not been hacked, and their systems were fine. Yet an assumption behind many of their online services had just collapsed.

The thieves were the Cl0p extortion group. Rather than locking up files, as ransomware gangs usually do, Cl0p was copying data and threatening to publish it. Its way in was a SQL injection flaw in MOVEit, catalogued as CVE-2023-34362, which Progress disclosed on May 31. SQL injection is a long-known class of bug in which an attacker types database commands into a box meant for ordinary input, and the system obediently runs them. On June 7, CISA, the federal government’s cybersecurity agency, and the FBI published a joint advisory on the campaign.

That advisory filled in the mechanics. Open-source reporting put the start of exploitation at May 27, a holiday weekend in the United States. Attackers installed a web shell the advisory called LEMURLOOT on internet-facing MOVEit servers, which let them list and pull stored files. CISA had added the flaw to its catalog of known exploited vulnerabilities on June 2. The advisory also set the campaign in context. The same group had used zero-day flaws in Accellion’s file transfer appliance in 2020 and 2021, and in Fortra’s GoAnywhere product in early 2023, where it claimed about 130 victims. File transfer servers had become its favorite target because they hold, by design, the files an organization most needs to send outside its walls.

The story kept moving through June. Progress disclosed further MOVEit flaws as researchers combed the code, and customers had to patch more than once. Cl0p posted a demand on its leak site telling victims to make contact. It also claimed it had deleted any data taken from governments, cities and police, a claim officials had no way to check and the states had no reason to rely on. On June 16, the US government offered a reward of up to $10 million for information on the group.

During the week, more public-sector disclosures followed. They included CalPERS, California’s public pension system, whose retiree data was exposed through a vendor’s MOVEit server. CalPERS never ran the software itself; a company it worked with did. That vendor, PBI Research Services, helped CalPERS identify deceased members and prevent overpayments, which is to say it was part of the pension system’s own fraud controls. CalPERS said PBI notified it on June 6. The exposed retiree data included names, dates of birth and Social Security numbers, and in some cases the names of spouses and children. CalPERS offered two years of credit monitoring and identity restoration. Press reports noted that PBI also served other state pension systems.

Both Louisiana and Oregon urged residents to watch for fraud and consider freezing their credit. Louisiana’s list went further, pointing residents to an IRS Identity Protection PIN and a my Social Security account. That was sensible advice for the people in the files. It said nothing, though, about the agencies across those states that had been using the very same license details as a way to tell residents apart from impostors online. For them, the breach had just happened too.

MOVEit reached most of its victims through vendors. The motor vehicle breaches raise a narrower question, one that matters to every state and local agency with an online service and to many banks, insurers and health systems as well. Once a whole population’s license records are in criminal hands, what happens to the identity checks that assumed those records were private?

Those checks stop working, all at once and without any alert to say so.

The argument runs in seven parts, in order. First, how license data came to do two jobs, identification and authentication, and how the checks are wired. Second, why a wholesale leak of a record set like this breaks those checks for everyone who relies on it. Third, the risk-tiered verification that should replace them. Fourth, what that costs and who pays. Fifth, what residents need to hear. Sixth, how an agency should run the first week after the next leak. Seventh, how to find the checks that depend on someone else’s secret before that leak arrives.

Two jobs for one piece of plastic

License data does two jobs in government, and they are easy to confuse.

The first is identification: a license number links a person to a record. It answers the question “which John Smith do you mean?” A name alone is ambiguous; a name plus a license number points to one file. Identification is a filing problem, and license numbers solve it well.

The second job, less visible, is authentication: proving that the person on the other end of a website really is the person they claim to be. Many online services ask a resident to type a license number, issue date or document discriminator to prove they are who they say. The discriminator is a hidden-in-plain-sight code printed on many licenses that changes each time a card is reissued.

Security professionals call this approach knowledge-based verification. It works like the security questions on an old online account, such as “what was your first pet’s name?” The system assumes that only the real person knows the answer. It is cheap, it needs no special equipment, and nearly every resident can complete it from a phone or library computer. That is why it spread.

And it is everywhere. Unemployment insurance portals used it during the pandemic. State tax departments use license details as an extra check on returns flagged for identity theft. Benefits applications, vehicle registration renewals, professional licensing and court payment systems often ask for them.

Some agencies use the license fields directly, comparing what a resident types against their own copy of the record. Others rely on commercial identity verification services. These outside companies take what the resident enters, check it behind the scenes against the motor vehicle record and other databases, and return a pass or fail. To the agency, the vendor’s answer looks authoritative. Underneath, it is often the same comparison.

How the checks are wired

The plumbing matters, because it determines what a “pass” proves. Three patterns account for most of what agencies run.

• Direct match against an in-state record. A benefits or revenue agency gets a feed or lookup from the motor vehicle agency under an interagency agreement. The resident types license number, issue date and date of birth; the system compares them with the record. A match proves that the person knows what the record says.
• Vendor match against motor vehicle and commercial data. An identity vendor takes the same entries and checks them against data it licenses. Some vendors route license checks through the national association of motor vehicle administrators, AAMVA, whose Driver’s License Data Verification service compares submitted fields with participating states’ records. Others rely on data brokers’ files. Either way, the vendor confirms consistency between what was typed and what is on file.
• Quiz-style questions generated from credit and public records. These ask the resident to pick a former street, a past lender or a county of residence from a list. They feel different, but they test the same thing: knowledge of facts held in commercial databases that have been breached repeatedly.

Not one of these patterns inspects a document or a face. Each confirms that the claimant holds information. Before June 2023, the working assumption was that holding all of the right information at once was hard. After it, for residents of two states, it was not.

Who sets the rules for whom

The rules on how strong these checks must be differ sharply by type of organization, which is one reason the weak ones lasted so long.

• Federal agencies are directed by OMB policy to follow NIST’s digital identity guidelines, SP 800-63, which define identity assurance levels. Those guidelines had long treated knowledge-based checks with suspicion.
• State and local agencies are generally not bound by NIST. Many cite it, some adopt it in state policy, and federal programs they administer, such as unemployment insurance and Medicaid, come with their own guidance and conditions. In practice, each program office has often made its own call.
• Banks and credit unions work under the customer identification program rule for new accounts and under interagency authentication guidance, refreshed by the FFIEC in 2021, for access to existing accounts. They also run identity theft red flags programs.
• Health systems and health plans are covered by the HIPAA Privacy Rule’s requirement to verify the identity of anyone requesting protected health information, which says little about how. Patient portal sign-ups and call centers often rely on date of birth, address and a record number.

The result is a patchwork in which the same leaked fields unlock different doors at different organizations, and no single regulator sees the whole exposure.

Consider how that plays out on an ordinary afternoon. Suppose a county resident wants to update the bank account that receives a benefit payment. She logs in, clicks “change payment details,” and is asked for her license number and its issue date. The agency’s system sends those values to its verification vendor. The vendor looks them up, finds a match, and replies “verified.” The change goes through, and the next payment lands in the new account. Nobody at the agency touched it, and nobody needed to. That is the efficiency these checks were bought for. It is also why, when the underlying data leaks, nobody notices: the process looks exactly as healthy as it did the day before.

In each case the assumption is the same. Only the genuine person, or someone holding the physical card, would know these values. That assumption was always weak. Licenses are photocopied by landlords, employers and car dealers, and copies sit in filing cabinets and inboxes across the country. MOVEit removed what was left of it in two states.

Why a wholesale leak breaks it for everyone

A breach of one agency’s files normally harms the people in those files. Their data is out; they may face fraud; the agency notifies them and offers help. It is serious, but it is bounded.

A breach of a foundational record set is different. A foundational record set is a body of data that many other organizations treat as a fixed reference point. Motor vehicle records are one. When that benchmark is exposed, it changes the verification assumptions of every organization that relies on the same data, whether or not that organization ran the vulnerable software.

The motor vehicle exposures amounted to a copied master key. If a building manager’s master key is copied, it does not matter that your own office door was never forced; your lock now opens for someone else. Every online service that used license details as a password was in that position.

Three features made them especially damaging.

• Coverage was near total. Louisiana believed nearly every license, ID and registration holder was affected. A fraudster could expect to find almost any adult resident in the data.
• The fields were exactly those used in checks. Name, date of birth, address, license number and physical description are the answers to the very questions online services were asking.
• The data does not expire on any useful timescale. A license number can stay the same for decades, and agencies rarely reissue numbers after a breach because doing so is expensive and disruptive. A stolen credit card number can be cancelled in a day. A stolen license number is likely to stay usable for many years.

The practical consequence is that a check passed with stolen license data looks identical to a legitimate one. The fraudster types the right number, the right date, the right address. Fraud teams cannot tell them apart from the answers alone. Agencies that treated a correct license number as strong evidence were, from June 2023, treating public information as a credential.

How a fraudster uses a file like this

Stolen record sets are rarely used alone. Fraud crews merge them with other breach data, phishing results and purchased phone numbers to build complete profiles. A motor vehicle file adds two valuable things: authority, because it is the state’s own record, and completeness, because it covers nearly everyone.

The profiles feed two kinds of attack. In account takeover, the fraudster passes verification on an existing account, changes the contact details, then moves the money. In first-party registration, the fraudster opens the online account for a resident who never created one, and controls it from the start. Benefits, tax refunds and unclaimed property are attractive because the payout goes to an account the fraudster names.

The Louisiana fields made both easier. Social Security number, date of birth, address and license number are the core inputs to most remote identity checks in the country. A fraudster holding all four for a given resident can pass many checks that were designed on the assumption that nobody would.

Why the monitoring does not catch it

Fraud teams have traditionally watched for failure. Repeated wrong answers, many attempts from one device, or a burst of lockouts all signal someone guessing. Stolen-but-correct data removes that signal. The attempt succeeds first time, from a clean device, with no failed answers to count.

What remains are patterns at the level of the transaction, not the check. Examples include a contact-detail change followed closely by a payment change, many accounts pointing to the same bank account or phone number, and new devices on long-dormant accounts. An agency that measures only pass and fail rates on its identity checks will see nothing unusual. An agency that tracks the sequence of changes on an account has a chance.

The strongest objection

A fair objection is that license data was never secret. Earlier breaches, data brokers and photocopies had already spread it. On that view, MOVEit changed little.

The objection is right about the trend and wrong about the effect. Earlier leaks were scattered and partial; a fraudster had to stitch them together and often had stale addresses. These files were complete, current and authoritative for an entire state. They lowered the cost of an attack from research to lookup. Security controls fail at the point where an attack becomes cheap and scalable, and these leaks took license-based checks to exactly that threshold.

Suppose a state unemployment agency lets claimants change the bank account where benefits are paid, provided they enter their license number and issue date. The state’s own DMV was never breached, but a neighboring state’s was, and many of its residents once held licenses there or moved from there. Within weeks, the agency sees a rise in payment redirections that all passed verification. Nothing in its own logs looks like an attack. Every check succeeded. That is what it looks like when someone else’s breach becomes your fraud problem.

What should replace it: verification by risk tier

No single control replaces knowledge-based checks. The workable answer is to sort transactions by the harm a wrong decision would cause, then require stronger evidence where the harm is higher. Practitioners call this risk-tiered identity proofing: the more damage an impostor could do, the more proof you ask for.

Low-risk transactions

Checking an application’s status or booking an appointment can continue to accept knowledge factors such as license details. An impostor gains little. Ideally these checks are combined with signals the attacker does not control, such as a device the resident has used before. Many systems can recognize a returning phone or computer in the background without asking the resident to do anything.

Low risk does not mean no controls. Rate limits on status lookups stop the page from being used to test whether a stolen record is valid before a higher-value attack.

Medium-risk transactions

Changing a mailing address or contact details should require a second channel. A one-time code sent to contact details already on file works, as does a letter to the address on record before the change takes effect. The delay is a feature, not a flaw: it gives the genuine resident a chance to object. Fraudsters change contact details first precisely so that later warnings go to them.

The notice to the old channel is the control that does the work. An email or letter to the address on file, saying that details were changed and how to dispute it, turns every genuine resident into a fraud detector. The hold period has to be long enough for the notice to arrive and be read. Agencies that skip the hold to reduce complaints give that advantage back.

High-risk transactions

Redirecting benefit payments, issuing a replacement credential or releasing tax refunds need evidence that cannot be copied from a breached file. Options include:

• Document verification with a live selfie match. The resident photographs their physical license and then takes a live selfie; software checks that the document looks genuine and that the face matches. A stolen spreadsheet row cannot pass this.
• In-person proofing at an agency office or partner location, where a trained person examines the document and the person together.
• Verification through a federated government identity service, meaning a shared sign-in service that has already proofed the resident to a known standard, so each agency does not have to repeat the work. Federated means one trusted identity, accepted by many services.

Each needs an alternative for people who cannot or will not use biometrics. Not everyone has a smartphone with a good camera, and some residents object to facial matching on principle.

Signals the attacker does not hold

Strong proofing at the front door is half the answer. The other half is checking signals that a stolen file cannot supply, at the moment of a risky change:

• Device and account history. Is the device one this resident has used before, and how long has the account existed?
• Phone number tenure and recent SIM changes. A number that moved to a new SIM yesterday deserves more scrutiny than one held for years.
• Bank account ownership. Account validation services can confirm whether a new payment account is open and, in some cases, whether the name on it matches the claimant.
• Linkage across accounts. Many claimants sharing one bank account, phone or mailing address is a strong signal of organized fraud.
• Death records. Benefits paid to someone who has died, or claims opened in their name, are a well-known pattern.

Because these checks ask the resident to do nothing extra, they are the cheapest way to raise assurance without raising friction.

Mapping the tiers to the standard

Agencies do not need to invent their own vocabulary. NIST’s identity assurance levels give a ready scale. Roughly, low-risk transactions sit at the lowest level, where no proofing is required. High-risk ones call for the middle level, which requires real evidence such as a document and a match to the person presenting it, remote or in person. The highest level, which requires physical presence or its supervised equivalent, is rare in citizen services.

Using the standard’s terms has a practical benefit. Vendors, auditors and federal partners already understand them, and a contract can require a named level rather than a vague promise of strong verification.

Making the tiers real

The tiering has to be explicit and owned. A program office should sign a short table listing each transaction, its risk tier and the evidence required. That table becomes the thing auditors test and vendors are contracted against. Without it, tiering exists only in a slide deck.

Agencies buying identity verification should also ask vendors which data sources each check relies on. A check that compares entered license data with the motor vehicle record proves nothing once that record is public. The vendor’s dashboard may still say “verified” in reassuring green. The question is what, exactly, has been verified.

What to put in the vendor contract

Most agencies buy identity verification as a service, so the contract is where tiering becomes enforceable. Useful terms include:

• A list of the data sources behind each check, and notice when a source changes or is known to be compromised.
• Reason codes for each result, so the agency can see which elements matched rather than a single pass or fail.
• Agency control over thresholds and step-up rules, so it can tighten checks during an incident without a change order.
• Reporting on false rejections, broken down by channel and, where lawful, by demographic group, so exclusion is measured rather than guessed.
• Clear limits on retention and reuse of document images and face templates, checked against the state’s privacy and biometric laws with counsel.
• Audit rights and incident notification that cover the vendor’s own suppliers, since MOVEit showed how far down the chain a breach can start.

The cost of getting it right

There is a cost, and it deserves a straight look. Stronger proofing adds friction, and friction falls hardest on older residents, people without smartphones and people with thin credit files, meaning those with little borrowing history for verification services to check against. For a public agency, a check that legitimate residents cannot pass is not a security success. It is a denial of service to the people the program exists to help.

The tiering approach limits that cost to the transactions where fraud does real harm. A resident checking a status page should not need to take a selfie. A resident redirecting thousands of dollars in benefits reasonably can be asked to.

Who fails the stronger checks

Document-and-selfie checks fail legitimate people in predictable ways. Expired or damaged cards, names that changed after marriage, older phones with poor cameras, bad lighting and shaky hands all produce rejections. Some residents have no current photo ID at all. Facial matching accuracy also varies across demographic groups; NIST’s 2019 evaluation of face recognition algorithms found such differences in many of the algorithms it tested, though the size varied widely between products.

Those failures do not spread evenly. They fall on older residents, rural residents with weak connectivity, people with disabilities and people in housing crises, who are often the heaviest users of benefits programs. An agency that tracks only fraud prevented will not see them. It needs a second metric: legitimate residents who abandoned or failed verification, and how long they waited for an alternative.

Budgeting both sides

A credible business case lists costs on both sides. On the control side: per-check vendor fees, in-person staff and locations, call center volume from residents who get stuck, and appeals. On the loss side: fraudulent payments, the low recovery rate on money already sent, staff time to restore victims’ accounts, and reissued payments to residents whose benefits were stolen.

Federal money can shift the arithmetic for programs that states run on the federal government’s behalf. During the pandemic, Congress funded unemployment insurance modernization that included fraud prevention and equitable access. Agencies that framed identity work as both, rather than fraud alone, were better placed to use it.

The objection from the other side

Critics of stronger proofing make a serious point: selfie checks can be beaten too. Fraudsters use printed masks, replayed video and, increasingly, synthetic images injected into the camera feed. Each stronger control invites a new attack.

The point is fair and does not change the conclusion. A copied record can be reused at scale for almost nothing. Defeating liveness checks takes effort per attempt and leaves artifacts that vendors can learn to detect. The aim is to make each fraudulent claim cost more than it returns, rather than to make fraud impossible. A check built on stolen data fails that test; a document-and-face check, with alternatives and monitoring, mostly passes it.

The money side runs in both directions. Stronger checks cost money per transaction and in staff time for in-person alternatives. Weak checks cost money in fraudulent payments and in recovery efforts that rarely succeed. They also carry a harder-to-measure cost: genuine residents whose benefits were stolen must wait while the agency untangles it. Those residents tend to call legislators. Reputational damage to a public program is slow to repair.

What residents need to be told

Louisiana and Oregon told residents to monitor their credit and consider freezes. A credit freeze stops lenders from pulling a person’s credit file, which blocks most new loans and cards in their name. That advice addresses credit fraud. It does nothing about government benefits fraud, which does not touch a credit file at all.

Louisiana’s advice did reach two federal programs. It pointed residents to the IRS Identity Protection PIN, a number that must accompany any tax return filed under their Social Security number. It also urged them to open a my Social Security account before anyone else could. Both work because they replace knowledge with something issued to the resident. State-run programs, from unemployment to state tax refunds, had no equivalent message.

Residents needed three further messages.

1. The agency will never ask for license details by phone or text, so any such request is a scam. Breaches are followed by phishing, because criminals know people are anxious and expecting contact.
2. How to report suspected misuse of their identity to each major program: unemployment, tax, benefits and vehicle titles. Each has its own process, and residents should not have to discover them one by one.
3. Where they could set up an account protected by stronger sign-in before a criminal did it for them. Pre-registration matters because many benefits frauds rely on creating the first online account in a victim’s name. Whoever registers first often controls the account.

These messages need coordination across agencies that rarely talk to each other. A state chief information officer or chief privacy officer is usually the right owner. Waiting for each program to issue its own notice produces inconsistent advice, and inconsistency is what phishing campaigns exploit. If one agency says “we will text you a code” and another says “we never text,” a criminal’s text slips through the gap.

Who sends what, and how

A coordinated notice needs a short list of decisions made in advance. One owner signs the message. Each program supplies a single line on how to report misuse and a single place to do it. The message goes out by the channels residents already trust, usually letters and the agencies’ own websites, and avoids clickable links in texts and emails, since those are what phishing imitates. Translations go out at the same time as the English version.

Pre-registration advice carries its own risk. Telling residents to create accounts invites fake “register now” messages. The answer is to name the official site in plain words, repeat it consistently, and never send a link.

Agencies also need to tell residents what they will do. A line saying that changes to payment details will now trigger a letter to the address on file, and a short delay, prepares residents for the friction and makes it legible as protection.

The first week after the next leak

A well-prepared agency, faced with news that a foundational record set has leaked, does a few things quickly. It pulls its transaction-and-tier table off the shelf and identifies every transaction that leans on the exposed data. It asks its identity vendors, in writing, which checks depend on that data. It temporarily raises the evidence required for the highest-risk changes, accepting some extra friction for a period. It joins a statewide message rather than writing its own. And it watches for the signals that matter most: spikes in contact-detail changes and payment redirections that passed verification.

A sequence for the first month

1. Days one and two. Confirm which fields were exposed and for whom. Map them against the transaction table. Decide, at the program director level, which high-risk transactions get a temporary step-up, and write that decision down with its expected effect on residents.
2. Days three to five. Receive vendors’ written answers on data dependence. Adjust thresholds and step-up rules. Brief call center staff, because the phone channel is where fraudsters go when the website hardens. Agree the statewide message.
3. Weeks two to four. Review the data: rates of contact-detail changes, payment redirections, step-up failures and abandonment. Relax controls that are excluding residents without catching fraud. Keep the ones that are working, and record why.

Auditors and inspectors general will later ask for evidence. The useful record is short: the transaction table, the decision memos with dates and owners, vendor responses, and before-and-after metrics. Agencies that kept it can show they acted on a known risk. Agencies that did not will struggle to show anything at all.

The ways agencies get it wrong are just as recognizable.

• Treating it as someone else’s breach. “Our systems were not affected” is true and beside the point. The assumptions were affected.
• Trusting the vendor’s green tick. A verification service that checks typed data against a now-public record still returns a pass. The tick means “the data matched,” not “this is the person.”
• Raising friction everywhere. Applying the strictest checks to every transaction punishes legitimate residents and often pushes them to phone lines and offices, which then become the weak point.
• Forgetting alternatives. A selfie step with no in-person or assisted option excludes residents who cannot use it, and can create legal and political problems of its own.
• Relying on credit-freeze advice alone. Benefits fraud does not touch a credit file.

Outside government, the pattern is the same. A regional bank that lets customers reset online access using license number and date of birth has the same exposure. So does a health plan that verifies members over the phone with similar details. Any organization that uses widely held data as a password should assume, after a breach like this, that the password has been published.

How it differs outside government

The response looks different by sector, because the rules and the money differ.

• Credit unions and community banks should fold the event into their identity theft red flags program and their authentication risk assessment. Call center resets based on date of birth and license number are the usual gap. The fix is often a callback to the number on file or a code to an enrolled device.
• Broker-dealers and investment advisers fall under the SEC’s identity theft red flags rule. Their high-risk transactions are address changes followed by withdrawal requests, and many already hold such requests for verification. A leak like this is a reason to confirm that the hold applies to every channel.
• Health systems should look at patient portal enrollment and password resets, which frequently rely on date of birth and address. Medical identity theft is slower to surface than payment fraud, so the review cannot wait for complaints.
• Health plans handle member calls about claims, address changes and replacement cards. Agents need a script that does not treat license or Social Security details as sufficient on their own.
• Counties and cities run property tax, utility and court payment portals that rarely carry high-value payouts, but they do handle refunds and account changes. A brief review of which of those accept license data is usually enough.

Finding the checks that rest on someone else’s secret

• Which of our online and phone transactions accept license numbers, dates of birth or other motor vehicle data as proof of identity, and has anyone signed a table putting each into a risk tier?
• For each identity verification vendor, which data sources does each check rely on? Would any of those checks still pass if the fraudster held the whole motor vehicle file?
• What happens today when someone changes a mailing address, phone number or bank account? Does the genuine resident get notified on the old channel, and is there a delay before money moves?
• What evidence do we require before redirecting payments or issuing a replacement credential, and could it be copied from a breached file?
• What is our alternative for residents who cannot or will not use a selfie or smartphone check, and is it funded and staffed?

Asking these questions takes no technical expertise. Answering them takes someone who owns the answer. In a state, that is usually a program director, with the state CIO or chief privacy officer coordinating across programs. In a bank or health system, it is the business owner of each channel, with the fraud or identity team holding the inventory.

The answers should produce three artifacts. The first is the signed transaction table, with tiers and required evidence. The second is a dependency list showing, for each check, which outside record sets it relies on. The third is a playbook for the day one of those record sets leaks, with named owners and pre-approved step-up rules.

None of the three is expensive. Each can be built from interviews and existing documentation in weeks, not months. Their value shows up only on a bad day, which is why they are so often missing.

A breach elsewhere should never be the first time an organization discovers which of its secrets were never really secret.

With hindsight

MOVEit became one of the largest data theft campaigns on record, touching thousands of organizations, many of them through vendors rather than through software they ran themselves. The security firm Emsisoft, which kept a running tally from public disclosures, counted 2,773 organizations and about 95.8 million individuals by June 2024. Education, health, and finance and professional services were the most affected sectors in its count. For many leaders it became the defining example of how a flaw in one widely used tool can ripple outward into organizations that never installed it.

Government disclosures kept coming through the summer of 2023. Other state agencies reported exposures through their own servers or through contractors, including Maine’s state government and Colorado’s Medicaid agency. Lawsuits against Progress and many of the affected organizations were consolidated into a single federal proceeding in Massachusetts later that year. Notification letters, credit monitoring and litigation absorbed much of the response effort. The identity checks that depended on the stolen data drew less public attention.

The stakes for benefits programs were clear from other work. In 2023 the Government Accountability Office estimated that fraud in pandemic unemployment insurance programs was likely between $100 billion and $135 billion. Much of it relied on stolen identities. That estimate made the cost of weak verification concrete in a way the MOVEit notices did not.

The motor vehicle exposures fed a shift in government identity practice that was already under way. Login.gov, the federal government’s shared sign-in service, had been criticized by GSA’s inspector general in March 2023 for telling partner agencies it met NIST’s requirements for remote identity proofing when it did not. It later added a selfie step to confirm that a person owns the ID they present. In-person verification at post offices remained an alternative for those who prefer it or cannot use the online route. That pairing, a stronger digital check alongside a human one, is close to the tiered approach described above.

NIST, the federal standards body whose digital identity guidelines many agencies and vendors follow, finalized a major revision of those guidelines, SP 800-63-4, in July 2025. The revision paid more attention to alternative proofing paths and to the risks of relying on data an attacker may already hold. Its identity proofing volume states that knowledge-based verification shall not be used for identity verification, while allowing it as one input to a fraud management program. It requires credential service providers to run a fraud management program, including a check against death records. It also formalizes trusted referees, trained staff who can make a reasoned decision for applicants who cannot meet the normal evidence requirements. The official rulebook had caught up with the problem that MOVEit made so visible, and it pairs stronger proofing with a defined route for people the stronger checks would exclude.

The foundational-data problem also recurred. In 2024, files from National Public Data, a background check broker, circulated on criminal forums with names, addresses and Social Security numbers for a very large share of Americans. Each such leak further eroded the idea that knowing those facts proves anything.

More states issued mobile driver’s licenses, digital versions of the license held in a phone wallet, and more agencies began accepting them. The TSA accepted mobile IDs from a growing list of states at airport checkpoints. Unlike a license number typed into a form, a mobile license can be checked cryptographically, which makes it much harder to fake with stolen data alone. Adoption remained uneven, and few benefits portals required one.

Selfie-based checks did not end the contest either. Vendors and researchers increasingly reported attempts to defeat them with manipulated or injected images, and liveness detection became a selling point in its own right. That fits the argument above: stronger proofing raises the cost of each attack rather than ending fraud.

Knowledge-based checks did not disappear, and public evidence on how individual agencies adjusted is thin. Many still ask for license details somewhere in their processes, often for good reasons of cost and accessibility. State programs remain outside NIST’s formal reach, so the 2025 revision guides them only to the extent they choose to follow it.

The underlying point stands, and it travels well beyond government. A breach of a record set that others rely on changes the assumptions of everyone who relies on it. The practical response is to know which of your controls depend on someone else’s data staying private, and to have decided in advance what you will do on the day it does not.