Third-Party Breach Exposed Records of Nearly 28 Million Texas Drivers

A breach at a third-party Texas.gov payment services vendor exposed the records of approximately 27.7 million Texas drivers, according to the Texas Department of Public Safety. Compromised data included driver's license numbers, home addresses, dates of birth, and vehicle registration history. DPS systems themselves were not penetrated.

The vendor first flagged the problem in December 2022, when it detected an anomalous increase in customer activity and notified DPS of a likely security incident. The nature of that anomaly — a volume spike rather than, say, a detected exfiltration alert — points to the kind of account-enumeration or credential-stuffing pattern that often surfaces through billing and transaction telemetry before it shows up in a SIEM.

The breach being vendor-side rather than agency-side is a meaningful technical distinction, but it offers only limited comfort to affected individuals. From the perspective of someone whose license number, address, and date of birth are now potentially in circulation, the proximate cause of exposure is secondary. The data is just as actionable for identity fraud, targeted phishing, or synthetic identity construction regardless of which server it left from.

The scale here — roughly 28 million records — covers a substantial fraction of Texas's adult population. Driver's license numbers combined with addresses and dates of birth constitute a high-value identity bundle. Alone, any one of these fields is low-risk; together, they can satisfy the knowledge-based authentication (KBA) questions used by financial institutions, government portals, and insurance providers. That combination is what elevates this above a run-of-the-mill credential dump.

The broader context here is one the industry has been grappling with for well over a decade. Government agencies increasingly deliver services through third-party vendors — payment processors, identity verification platforms, document management systems — and each integration extends the effective attack surface of the agency. A department can harden its own perimeter to a high standard and still carry substantial downstream risk through its vendor ecosystem. The Texas incident is a clean example of that structural gap: DPS's own infrastructure held, but the exposure occurred in a contracted layer that handles real, sensitive transactions on the agency's behalf.

Worth flagging for practitioners: the detection vector itself deserves attention. The vendor identified the incident through a customer-volume anomaly, not through endpoint detection, log analysis, or an external threat intelligence feed. That is not unusual — billing and access-count anomalies have historically been underrated as early-warning signals — but it raises a question about what continuous monitoring obligations exist in the contractual relationship between a state agency and its payment processor, and whether those obligations were sufficient to minimize the window of exposure.

DPS has published guidance for affected individuals at its driver license security incident page. Standard recommended actions apply: place a security freeze with the three major credit bureaus, monitor for new account activity, and be alert to phishing attempts that leverage known personal details — which, given the richness of this dataset, could be highly personalized.

For state agencies currently auditing their own vendor relationships, the Texas case is a useful benchmark. The question is not whether a given vendor has SOC 2 or FedRAMP documentation on file, but whether the monitoring telemetry — transaction volumes, API call rates, access-pattern baselines — feeds into a joint detection workflow with the agency, or sits entirely within the vendor's own operations center, invisible until the vendor itself decides to report.