National Public Data turned the Social Security number into a lookup key

The week

In mid-August 2024, National Public Data acknowledged on its website that it had suffered a breach. Most Americans had never heard of the company, and most never did business with it. That was precisely the problem.

National Public Data was a Florida-based background-check data broker. A data broker is a company that collects personal information from public records, commercial sources and other databases, stitches it together into profiles, and sells access to those profiles. Its customers are often landlords, employers, investigators or anyone else willing to pay for a search. People do not sign up to be in these databases. They are simply swept in.

Months of warning before the notice

By the time of the acknowledgment, the stolen data had been circulating for months. As BleepingComputer and KrebsOnSecurity reported, a criminal using the name USDoD offered a dataset said to come from the company for sale in April 2024. The asking price was $3.5 million, and the seller described it as 2.9 billion records covering people in the United States, Canada and the United Kingdom.

Copies then began to leak. Partial versions appeared on a criminal forum in July. On August 6 another actor posted what BleepingComputer called the most complete version for free: two text files totaling 277 gigabytes and nearly 2.7 billion plaintext records.

The company’s own statement, posted on August 12, said the incident appeared to involve a third-party bad actor who had tried to hack into data in late December 2023. It said there were potential leaks in April 2024 and in the summer. It listed names, email addresses, phone numbers, Social Security numbers and mailing addresses as the kinds of information involved.

Rows, not people

Early headlines spoke of billions of people. That was wrong, and the correction matters for how organizations should read the event. The files held one row per person and address, so the same person could appear many times, and some entries were out of date or simply mistaken.

Independent analyses narrowed the picture. Troy Hunt, who runs the breach notification service Have I Been Pwned, described a disparate mix of consumer and business records. One analysis reported by KrebsOnSecurity counted about 272 million unique Social Security numbers. It found the records skewed toward older people, and included many who were likely deceased.

The files were alarming for their shape as much as their size. They linked names, mailing addresses, dates of birth and Social Security numbers, and they covered many people who had never dealt with the company. The exact combination of facts that banks, hospitals and government agencies routinely ask for to confirm “is this really you?” was now sitting together, person by person, in a file anyone could download.

The week itself

Through mid-August, security researchers examined the files to understand what was in them. Consumer advocates urged people to place credit freezes, which block new credit from being opened in their name until they lift the freeze. Class actions against the company piled up in federal court in Florida, including one filed in the Southern District of Florida on August 19.

The same day, KrebsOnSecurity reported that a sister background-search site had left an archive online containing its source code and plaintext usernames and passwords, including an administrator’s login. For a company that had just lost a national-scale dataset, the report raised further doubts about its basic security practices.

The company did not last long after that. National Public Data, legally Jerico Pictures, Inc., filed for Chapter 11 bankruptcy protection at the start of October 2024.

The reaction split along familiar lines. Consumers were told to freeze their credit and watch their statements. Little of the public advice addressed the organizations on the other side of the transaction: the banks, health systems and agencies whose identity checks used the same facts that were now in the files.

For any organization that verifies identities, the week’s real news was less that one broker had been careless. A long-weakening security habit, treating personal facts as proof of identity, had finally lost whatever value it had left.

A caller rings a bank’s contact center. She is calm and polite. She gives her full name, her date of birth, the last four digits of her Social Security number and her home address, all correct. She explains she has a new phone and needs to reset her online access. The agent, who is measured on how quickly and smoothly calls are resolved, helps her. Two days later the real customer’s savings are gone.

Social Security numbers had been leaking for a decade before August 2024. The National Public Data files changed the packaging. They joined identity attributes into one searchable record per person and made the set cheap or free. That ended any remaining case for treating a Social Security number, date of birth and prior address as proof of identity.

Those facts still have a job: they let an organization find the right record. They can no longer authenticate the person supplying them. The distinction hides inside everyday operations in banking, healthcare and government, and each of those places needs its own fix.

The sections below set out the distinction first. They then take the three journeys where it matters, enrollment, recovery and high-risk changes, before turning to where the cost lands, where the old questions linger, and what to ask.

Finding a record is not proving who is asking

Two words do most of the work here, and they are often blurred together.

Identifying someone means working out which record they are talking about. A name and date of birth help a hospital pull up the right chart among thousands of patients with similar names. A Social Security number helps an agency find the right benefits file. This is a lookup, like a library catalog number that tells you which shelf a book is on.

Authenticating someone means confirming that the person in front of you, on the phone or on the website, is the person that record belongs to. That requires something only the genuine person has: a key, not a catalog number.

For decades, many organizations used the same facts for both jobs, on the theory that only you would know your Social Security number and birth date. Security professionals call these “knowledge-based” checks. They were always weak, because the facts are written on many forms and stored in many systems. Once a single file linked them for vast numbers of people, the assumption collapsed entirely. A fact that anyone can buy, or download for free, proves nothing about who is supplying it.

Why the packaging mattered more than the size

Before 2024, a criminal who wanted to pass a knowledge check usually had to assemble the answers. A Social Security number might come from one breach, an address from another and a birth date from a social media profile. Each join took effort, and errors crept in.

A broker file does the joining in advance. It hands over a complete, consistent set of answers for each person, including previous addresses, which some checks ask about precisely because they seem obscure. When that set is free, the marginal cost of an attempt falls toward zero. A fraud ring can then try many identities and accept a high failure rate, because each attempt costs almost nothing.

The data did not have to be perfect to be useful. Stale addresses and wrong links meant some attempts failed. But a check that stops only the attempts using bad data is a filter on data quality, not on identity.

The age profile reported in one analysis also mattered. Records skewed toward older people and included many who were likely deceased. Older customers are frequent targets of account takeover, and the identities of the dead are a known raw material for fraudulent new accounts. Both groups are less likely to notice misuse quickly.

Rules built on the same facts

Part of the difficulty is that several rules require organizations to collect these facts, and some describe matching them as a form of verification.

Under the Customer Identification Program rules issued under the Bank Secrecy Act, banks and credit unions must collect four facts before opening an account. They are a customer’s name, date of birth, address and an identification number, usually a Social Security number for US persons. Broker-dealers have a parallel rule. The rules allow verification through documents or through non-documentary methods, which include comparing the information against a consumer reporting agency, a public database or another source. Those sources overlap heavily with what brokers sell.

The rules are not wrong to require collection. An institution needs those facts to identify a customer and to file reports. The risk lies in treating a successful match as the end of verification. The rules set a floor, and the floor assumed facts that were harder to obtain than they became.

Healthcare has a similar pattern. The HIPAA Privacy Rule requires covered entities to verify the identity and authority of a person requesting protected health information when that person is not known to them. It does not prescribe a method. Many portals and call centers met it with a birth date and an address.

Federal agencies have more specific guidance. OMB has directed agencies to follow NIST’s digital identity guidelines, the SP 800-63 series, which had already restricted the use of knowledge-based verification well before 2024.

What stronger authentication rests on

Stronger authentication generally relies on one of three things. The first is something you have: a registered phone, a hardware security key or a passkey stored on a device. The second is something you are, such as a face or fingerprint matched to a verified document. The third is a history the organization can observe, such as a phone number that has been on file for months or a device it has seen before. A passkey is a modern login method that uses a secret stored on your phone or computer and unlocked with your fingerprint, face or device PIN. There is no password or personal fact for a criminal to steal or guess.

Separating “identify” from “authenticate” is simple to say and hard to apply, because knowledge checks are embedded in three customer journeys that work differently. Enrollment decides whether a new person is real. Recovery decides whether a returning person who has lost access is the owner. High-risk changes decide whether a logged-in session should be allowed to redirect money, mail or alerts. Every point where a bank, health system or agency trusts a person falls into one of these three.

Enrollment: matching data the attacker also holds

Opening a deposit account, registering for a patient portal or applying for benefits online often relies on matching typed details against a reference source. Many identity verification services, the outside vendors that check whether an applicant is who they claim to be, draw on the same kinds of commercial records that brokers assemble. A match confirms that an identity exists. It says nothing about whether the applicant owns it, any more than confirming that a visitor’s address is real proves they live there.

Stronger enrollment adds evidence the attacker is unlikely to have: a verified identity document, a live check that the person matches it, and signals about the device, phone number tenure and connection. The live check, often called liveness detection, asks the applicant to take a selfie or short video. Software then confirms that a real person is present and that their face matches the photo on the document. Phone number tenure means how long a number has been in use by the same subscriber; a number activated last week is a warning sign that a number in use for years is not.

What each enrollment check proves

Enrollment vendors sell several kinds of check, and each proves something different:

• Data matching proves that a name, birth date, address and Social Security number appear together in some reference source. After August 2024, the attacker could produce the same match.
• Issuer verification, such as the Social Security Administration’s consent-based verification service for financial institutions, confirms that a name, birth date and number match government records. That catches invented, or synthetic, identities. It does not catch a criminal using a real person’s true details.
• Document and liveness checks tie the applicant’s face to a government document. They are much harder to pass with purchased data, though forged documents and computer-generated faces are a growing problem.
• Possession checks confirm that the applicant controls something linked to the identity, such as a long-held phone number or an existing bank account.
• In-person proofing puts a trained person in front of the applicant and the documents. It is the strongest and the least convenient.

Layering these checks by risk is the practical answer. The first two are cheap and fast. The rest add cost and friction, and should be applied where the account carries real value or real data.

Synthetic identities

Enrollment faces a second threat besides the stolen true identity. A synthetic identity combines a real Social Security number, often one belonging to a child, an older person or someone who has died, with a made-up name and birth date. The fraudster builds a credit history for that invented person over months, then borrows heavily and disappears.

Broker files help here too. They show which numbers belong to people unlikely to notice misuse, and supply plausible addresses to attach. The defense differs from the stolen-identity case. Checks against issuer records, such as the Social Security Administration’s service, catch a name and number that do not belong together. Watching for many applications that share a phone number, device or address catches the factory behind them.

A credit union or community bank is a natural target, because synthetic identities are often built slowly through small accounts and secured cards. Losses frequently show up as credit losses rather than fraud, which hides the problem from the fraud team. Reviewing charged-off accounts for signs of synthetic identity is a cheap way to find out whether it is happening.

Proportion and alternatives

The design question is proportionality. A credit union opening a share account, a hospital granting access to lab results and a state agency paying unemployment benefits face different fraud economics and different equity duties. Agencies in particular must offer alternatives, such as in-person or trusted-referee options, for people who cannot complete remote document checks. A trusted referee is a trained person who can vouch for an applicant’s identity through other means. That matters for people without a current photo ID, a smartphone or a stable address.

The options differ by setting. A fintech that opens accounts entirely online has no branch to fall back on and leans most heavily on document and device checks. A credit union with branches can invite applicants who fail a remote check to finish in person. Many health systems already issue portal activation codes during a visit, which ties enrollment to a person the clinic has seen. Some federal services offer in-person verification at participating post offices.

Each of those alternatives costs money and staff time, and each is slower than a remote check. The trade-off is explicit: fewer fraudulent accounts and fairer access, in exchange for a more expensive and more varied process. Senior management should make that choice knowingly.

One concrete step concerns the vendor relationship: ask the identity verification provider to list which of its checks rely on data an attacker could buy, and to report pass rates for those checks separately. A check that passes nearly everyone, including known fraud, is a formality that adds cost and gives false comfort.

Recovery: the door attackers prefer

Attackers rarely need to enroll. Taking over an existing account is cheaper, and recovery is the easiest path. A contact center agent who asks for the last four digits of a Social Security number, a birth date and a mailing address is now checking facts that are in a downloadable file. The caller in the opening story did not need to hack anything. She only needed to read.

Recovery should rest on things the attacker does not have. Options include a registered device, a passkey or hardware key, a callback to a number that has been on file for months, or a step-up to the same document-and-liveness check used at enrollment. Each option needs a contact center script, a supervisor override rule and an audit trail, so that the process works the same way whichever agent answers and can be reviewed afterward.

The help desk is the same problem

The recovery problem is not confined to customers. Employee help desks reset passwords and multifactor devices every day, often after checking an employee ID number, a manager’s name or a birth date. Those facts are easy to find or guess. The September 2023 attack on MGM Resorts, widely reported to have started with a call to the company’s IT help desk, showed how much damage one persuasive caller can do.

The same controls apply inside the organization. Resets of privileged accounts should require a video call with ID, a manager’s approval through a separate channel, or an in-person visit. A reset should also trigger a notice to the employee’s existing contact details and a review of any changes made soon afterward.

Incentives decide behavior

Staff incentives matter as much as technology. Agents measured on handle time and first-call resolution are rewarded for helping a plausible caller. Adding a metric for safe refusals, and protecting agents who use it, changes behavior faster than a new tool. Consider an agent who says “I can’t reset this account on this call, but these are the other routes.” If that agent is marked down for an unresolved call, the organization is paying its staff to let fraud through.

Outsourced contact centers need the same treatment. Their contracts often pay by call volume or resolution rates. A provider paid that way has little reason to slow a plausible caller down. Contracts should include fraud outcomes and safe-refusal measures, and give the client the right to review recordings of recovery calls.

Two technical details that decide whether it works

First, the callback number must be one the attacker cannot change in the same session, so phone number changes need their own waiting period. Otherwise a criminal simply updates the number and then asks to be called back on it.

Second, SIM-swap and number-porting signals from carriers should feed the recovery decision, because a recently ported number is a common sign of takeover. In a SIM swap, a criminal persuades a mobile carrier to move a victim’s phone number to a new SIM card the criminal controls. In a port-out, the number is moved to a different carrier. Either way, every text message and call meant for the victim, including one-time security codes, now goes to the attacker.

The Federal Communications Commission adopted rules in November 2023 for wireless carriers. They require secure methods to authenticate customers before moving a number to a new device or carrier, and notice to customers of those requests. That helps, but a bank or hospital should not assume every carrier’s controls work every time. Its own recovery design should still treat a recent number change as a risk signal.

Take a regional health system. A patient calls to say she is locked out of the portal. Under the old script, the agent confirms her birth date, address and the last four digits of her Social Security number, then resets the account and sends a link to whatever email she gives. Under a new script, the agent can offer three routes. She can approve the reset from the phone already registered to her portal, or receive a callback on the number that has been on file since last year. Or she can complete the same document-and-selfie check she used when she first signed up. If none of those works, she is invited to bring photo ID to a clinic front desk. Nothing in the new script can be satisfied by reading a leaked file, and every route is logged.

How recovery differs by organization

The principle is the same everywhere, but the recovery population differs. A bank or credit union often knows its customers through branches and long account histories, which supports callbacks and in-branch recovery. A broker-dealer or wealth manager has fewer, higher-value accounts and a financial adviser who may know the client personally; the adviser can be part of the recovery path, provided the adviser’s own channel is protected.

A health system deals with caregivers acting for patients, parents of minors, and adolescents whose access rules change with age. Recovery for a proxy account must confirm the caregiver’s identity and their authority, which are separate questions. An ambulatory network may rely on its portal vendor’s recovery flow and should check that it does not fall back on birth date and address.

A public agency serves many people without a stable phone or email. Its recovery design needs an in-person or trusted-referee route that works for them, staffed at hours they can reach. Without it, the agency will face pressure to restore the old questions for everyone.

Recovery codes that the genuine person holds

Some organizations issue a second secret after strong verification. The Internal Revenue Service’s Identity Protection PIN, available to any taxpayer who verifies their identity, works this way: a tax return filed under that Social Security number must carry the PIN. The same idea can protect recovery. A customer or patient who completes a strong check can be offered a recovery code or a registered passkey, so a later lockout does not fall back on facts anyone can buy.

The customer experience cost is real but concentrated. Most legitimate users never need recovery in a given year. Those who do should get a clear explanation of why the old questions are gone, and a predictable path that does not depend on which agent answers.

High-risk changes: the step before the loss

Much of the damaging fraud follows a routine-looking change: a new mailing address, phone number, email, direct deposit account or payee. Once the change is made, the real customer stops receiving the alerts that would have warned them, and the criminal can proceed unobserved.

Public agencies saw this pattern at scale when benefit payments were redirected during the pandemic. Banks see it in payee and wire fraud. Health systems see it when portal accounts are used to obtain records or redirect prescriptions.

These events deserve controls separate from login. Logging in proves, at best, that someone has the credentials. It does not prove that the person should be allowed to change, unannounced, where money and messages go. Practical controls include:

• Notify the old contact details as well as the new ones, so the genuine customer hears about the change.
• Apply a short hold before a new payment destination becomes active, giving that notice time to land.
• Raise the verification bar when a contact change is followed within days by a payment, a benefit redirect or a records request.

Each of these can be tuned so that most customers never notice: the friction lands on the rare combination of events that fraud produces. A customer who moves house and updates her address sees nothing unusual. A “customer” who changes his phone number on Monday, his email on Tuesday and his direct deposit account on Wednesday meets a pause and a check.

An old rule that already encoded this

The idea is not new. The Identity Theft Red Flags rules, which apply to financial institutions and creditors that hold covered accounts, require programs to detect warning signs of identity theft. They include a specific duty for card issuers. When a request for an additional or replacement card arrives shortly after an address change, the issuer must assess whether the change is valid before issuing the card. The SEC applies a parallel rule, Regulation S-ID, to broker-dealers, investment advisers and funds that hold covered accounts.

The card-issuer duty captures the general principle in one narrow case: a contact change followed quickly by a request that sends value somewhere is a signal. Extending that logic to payees, direct deposit, portal email addresses and benefit accounts is a design choice, not a new invention.

The data problem behind the controls

Most organizations hold the signals these controls need in different systems. The address change is in the core or the patient registration system. The new device is in the online banking or portal logs. The payee or direct deposit change is in the payments platform, and the phone call is in the contact center. A rule that reacts to a combination of events needs those events in one place, close to real time.

Building that view is often the largest piece of work in the whole program. It usually means sending change events from each system to a shared fraud or risk engine, with agreed definitions of what counts as a contact change. The payoff is broad. The same feed supports account takeover detection, customer notifications and investigations.

Tuning the controls

The controls have costs, and the tuning matters. A hold on a new payee delays a legitimate first payment to a contractor. A hold on direct deposit changes can delay a paycheck or a benefit payment for someone who has just changed banks, which falls hardest on people with the least slack. Notices to an old email address are useless if that address has been abandoned.

Good tuning starts with data the organization already has. How often do legitimate customers change a payee and pay it within a day? How long do most genuine address changes take to be followed by a card request? Holds can be shortened for low amounts, long-tenured devices or changes made in person. Staff overrides should exist, be logged and be reviewed, because an override process that is never checked becomes a back door.

Say a county benefits office sees a claimant’s direct deposit account changed online, with a payment due three days later. Under the old process, the payment simply goes to the new account. Under the improved one, a letter and an email go to the address and inbox on file before the change. The new account is held for a few days. The combination of a recent contact change and an imminent payment triggers a stronger identity check. The genuine claimant who changed banks barely notices. The fraudster who hijacked the account does not get paid.

Where the cost lands when authentication fails

This is a problem for more than the fraud team.

Customers and patients blame the institution they trusted. When a stranger empties an account or reads a medical record, the victim rarely thinks about a data broker in Florida. They think about the bank that let the caller in or the portal that accepted the reset. The reputational cost lands where the authentication failed, not where the data leaked.

Recovery from the source is unlikely. The company at the center of this breach went into bankruptcy within weeks. Organizations whose customers are harmed cannot assume someone else will make them whole.

The law often puts the loss on the institution. Under Regulation E, a consumer who reports an unauthorized electronic fund transfer promptly has limited liability, and the bank or credit union usually bears most of the loss. In healthcare, an impostor who obtains records through a portal can turn a verification failure into an impermissible disclosure under HIPAA, with breach analysis and possible notification to follow. An agency that pays benefits to a fraudster often still owes the genuine claimant.

Regulators judge the control, not the excuse. “The criminal knew all the right answers” is not a persuasive defense when everyone in the industry knew those answers were for sale.

Equity and access are part of the design. Stronger controls that work only for people with the newest phones and a driver’s license shut out older customers, low-income residents and people in unstable housing. For public agencies this is a legal duty; for banks and health systems it is a customer and reputational one. Good design offers more than one strong path.

Ownership is often the harder problem. Login belongs to security, contact center scripts to operations, and payment holds to the business line. A named owner for each journey, with one fraud metric per journey, keeps the three from drifting apart.

What to report upward

A board or risk committee does not need every fraud statistic. It needs a few measures per journey that show whether purchasable facts still open doors. Useful ones are the share of recoveries completed without any knowledge question, confirmed takeovers per thousand recoveries, the number of high-risk changes held and later confirmed as fraud, and abandonment at each new step. Reported quarterly, by channel, these show whether the weakest channel is improving or simply being ignored.

The case for keeping friction low

There is a serious argument on the other side. Every added step loses some genuine customers. Contact centers cost more when calls take longer. A community bank or a rural clinic may judge that its fraud losses are modest and its members value easy service. Pushing everyone through document checks could cost more in abandoned applications and complaints than it saves.

That argument is right about blanket friction and wrong about the old questions. The answer is to stop relying on purchasable facts, then add friction only where risk concentrates: recovery, contact changes and new payment destinations. Most customers meet none of those in a typical month. Measuring abandonment and complaints alongside fraud, journey by journey, keeps the trade-off visible rather than argued from instinct.

How the knowledge questions survive

An organization that has adapted well uses Social Security numbers and birth dates only in record lookup, never in a decision to grant access or approve a change, including in fallback procedures. Enrollment uses evidence proportionate to the risk, with alternatives for people who cannot complete remote checks. Recovery runs on registered devices, passkeys, established callback numbers or a repeat of the enrollment check, with scripts and audit trails. High-risk changes have their own notifications, holds and step-up checks. Each journey has a named owner and a single fraud metric that senior management actually sees.

The old questions tend to linger in predictable places:

• On the phone after they leave the website. Attackers simply call. The weakest channel sets the real level of security.
• As a “fallback.” If the strong path fails and the agent reverts to birth date and address, the strong path is decorative.
• Behind a vendor’s overall pass rate. A high pass rate can mean a smooth experience or a check that never stops anyone. Without separate reporting for purchasable-data checks, you cannot tell which.
• In a phone number that can be changed and used in the same session. This turns a callback control into a gift for attackers.
• In agent scorecards that measure only speed. Staff will do what they are measured on.
• After login. Most of the loss happens once a session is open, through unannounced changes to where money and alerts go.
• At the employee help desk. The same questions that were removed from customer recovery often remain in the script for staff password resets.
• In branches and clinics. Front-desk staff may still accept a recited birth date and address in place of ID, because nobody updated their procedures.

Finding them

The quickest way to find lingering knowledge checks is to test them. A short internal review can collect every script, form and system rule that asks for a Social Security number, birth date or address, and mark each use as lookup or access. Mystery-shopper calls to the contact center, run with the fraud team’s agreement, show whether agents follow the new script under pressure. Reviewing a sample of confirmed takeover cases shows which channel the attacker used. Each method takes weeks, not months, and the results tend to persuade budget holders faster than policy memos.

Where knowledge checks still decide access

• Where in our organization, online, in branches, in clinics or on the phone, do we still accept a Social Security number, date of birth or address as proof of identity, including in fallback procedures?
• Which of our identity verification vendor’s checks rely on data an attacker could buy, and what are their separate pass rates?
• How are our contact center agents measured, and is there any credit for a safe refusal?
• Can someone change a phone number or email and then use it to recover the account in the same session?
• Who owns enrollment, recovery and high-risk changes respectively, and what single fraud metric does each report?

With hindsight

The breach sped up change that was already under way, though unevenly across organizations and channels.

The company itself offered almost nothing to the people harmed. Its bankruptcy papers cited more than a dozen class actions, investigations by the Federal Trade Commission and more than 20 states, an insurer that had declined coverage, and assets estimated at $25,000 to $75,000. Individuals could expect to recover little from the company. The organization where a fraud actually lands, the bank, the hospital, the agency, carries the practical consequences, whoever originally lost the data.

Regulating the brokers

Federal attempts to regulate the brokers stalled. In December 2024 the Consumer Financial Protection Bureau proposed applying the Fair Credit Reporting Act to data brokers that sell certain sensitive information. The proposal would have restricted the sale of identifiers such as Social Security numbers. In May 2025 the bureau withdrew it, saying further rulemaking was not necessary or appropriate at that time.

States moved instead. California’s Delete Act produced a single platform, known as DROP, through which residents could ask every registered data broker to delete their information. Residents could begin submitting requests on January 1, 2026, and brokers had to start processing them on August 1, 2026, checking the platform at least every 45 days.

Neither development changes the argument here. Deletion reduces what brokers hold from now on. It cannot recall files that have already been copied and posted. Organizations that verify identity still have to assume the facts are public.

The attackers adapted too

In November 2024, FinCEN issued an alert on fraud schemes using deepfake media. It reported a rise in suspicious activity reports describing suspected deepfakes. The most common concern was fraudulent identity documents used to get past identity verification and authentication controls. As knowledge checks lost value, attackers moved to the stronger checks that replaced them.

That shift confirmed the article’s structure. Enrollment did not become a solved problem once document checks arrived. It became a contest between better forgeries and better detection, which is why layering and in-person alternatives still matter.

The tools and the standards

The tools to do better arrived quickly. Passkeys spread across major consumer platforms through 2025, making device-bound recovery practical for many customers. A recovery process that once had to fall back on personal facts could increasingly rely on something the genuine customer carried in their pocket.

The standards caught up too. In July 2025 NIST published the final fourth revision of its digital identity guidelines, SP 800-63-4, a reference widely used by agencies and by many private organizations that model their practices on federal guidance. Its identity proofing volume states that knowledge-based verification shall not be used for identity verification, though it may still play a role in fraud management. It also says identity services should offer trusted referees when automated checks, such as face comparisons, fail.

The revision added controls against injection attacks and forged media in remote proofing and accepted synced passkeys. An injection attack, in this context, feeds fake images or video straight into the verification software instead of using a real camera. Those additions reflected how deepfakes, convincing computer-generated faces and voices, had begun to pressure document-and-selfie checks, which kept enrollment a moving target rather than a solved problem.

What lagged

The slowest part to change was the human one. Contact center recovery scripts lagged, because removing knowledge questions meant retraining staff and accepting longer calls. That is a budget and management decision more than a technical one, and it is where senior attention still pays off most. Changing the scripts without changing agent scorecards tends to let the old questions creep back as informal habits, because the scorecard still rewards the quick reset.

The distinction at the heart of this piece has held: facts that find a record are not facts that prove identity. NIST’s own guidance now says so explicitly for identity proofing, and examiners and auditors increasingly read it that way. Organizations that built their journeys around that line are in a stronger position as attackers’ tools improve. Data brokers themselves became a regulatory subject, though more in state capitals than in Washington.