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

The week

In mid-August 2024, National Public Data, a Florida-based background-check data broker, acknowledged on its website that it had suffered a breach. A dataset taken from the company had been offered for sale on criminal forums in the spring, and a version was posted for free in early August. Its sellers described it as billions of records. The files linked names, mailing addresses, dates of birth and Social Security numbers, and covered many people who had never dealt with the company. Coverage peaked around August 19 as researchers examined the files and consumer advocates urged credit freezes. The company’s own notice to the Maine attorney general listed about 1.3 million affected people, a figure widely seen as far below the true scope. Its parent company filed for Chapter 11 bankruptcy in early October 2024.

Social Security numbers had been leaking for a decade. 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.

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, and each needs its own fix.

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 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.

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 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 concrete step for 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. If a check passes nearly everyone, including known fraud, it is not a control.

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 sit in a downloadable file.

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. 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.

Two technical details decide whether this 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. 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.

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 quiet 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. 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. Notify the old contact details, not only the new ones. Apply a short hold before a new payment destination becomes active. 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.

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

With hindsight

The breach sped up change that was already under way, unevenly. The bankruptcy filing listed attorneys general from nearly every state among creditors, which signaled how little individuals could expect to recover from the company itself. Passkeys spread across major consumer platforms through 2025, making device-bound recovery practical for many customers. In July 2025 NIST published the final fourth revision of its digital identity guidelines, SP 800-63-4. It added controls against injection attacks and forged media in remote proofing and accepted synced passkeys. Those additions reflected how deepfakes had begun to pressure document-and-selfie checks, which kept enrollment a moving target. Contact center recovery scripts were the slowest part to change, because removing knowledge questions meant retraining staff and accepting longer calls. Data brokers themselves became a regulatory subject, which a later article in this series takes up.