The Florida Department of Highway Safety and Motor Vehicles says it learned of a data breach on September 4, 2026. ShinyHunters listed the agency on its leak site on September 7, according to The Record, and the agency confirmed the breach on September 11. Its statement attributes the intrusion to "a single Plant City Police Department user's credentials that were improperly housed on the employee's personal electronic device." Plant City is a city of roughly 40,000 east of Tampa. Its police department is not part of FLHSMV.
That is everything the agency has established. As of September 14 it has named no system, given no date range, published no record count and made no commitment to notify individuals. Florida Today's summary that day: "The department did not release any specifics about what information was leaked." The statement says the required notice went to the Attorney General under section 501.171, which puts the agency on the same discovery-to-notification clock as any Florida business. The attacker publishing three days before the victim spoke is the pattern this year, not an anomaly.
The device was never the state's to control
Every outlet has the personal-device quote and frames the breach as one officer's mistake. The more useful frame is structural.
FLHSMV issues logins to law enforcement agencies across the state so that officers can look up driver and vehicle records. Those agencies are not vendors. There is no contract with a security addendum, no right to audit, no leverage of the kind a managed IT provider's client at least nominally has. The state cannot push MDM to a Plant City officer's phone, cannot wipe it, and cannot see whether a password sits in a notes app. Whatever the interagency agreement says about credential handling is a document the other organization signed.
Once you accept that the endpoint is out of reach, the grantor's control surface collapses to two things it still owns outright: what one account is entitled to reach, and whether anyone notices how much it reaches. Nothing in the September 11 statement says anything about either. "Quickly mitigated" tells you the credential was disabled. It does not tell you what that credential could enumerate in the interval before it was.
Scope and rate are the controls you keep
The practice is to treat every externally held account as an account you will eventually lose, and to size it so that losing it is survivable.
Entitlement scope. An investigator needs to look up a specific person or plate. An investigator does not need to page through a table. Those are different permissions, and most partner-facing record systems grant the second because it was easier to build. Scope each partner role down to lookup by identifier, with no wildcard search, no bulk export and no API listing endpoint. If the system cannot express that, put a query gateway in front of it that can.
Query volume. One officer runs a bounded number of lookups in a shift. A stolen credential in a scripted session does not. The signal is per-account distinct subjects per hour, and it is cheap to compute if the access log records the subject of each lookup rather than just the login event. Most do not, and that is the first fix.
SELECT account_id, issuing_org,
COUNT(*) AS lookups,
COUNT(DISTINCT subject) AS distinct_subjects
FROM record_access_log
WHERE ts > now() - interval '1 hour'
GROUP BY 1, 2
ORDER BY distinct_subjects DESC
LIMIT 20;
If that query returns an account at ten times its own thirty-day median, something should page. If the log cannot answer it, no amount of partner-side policy substitutes.
MFA on your side. A second factor enforced by the partner's identity provider protects the partner's tenant. It does nothing for the system you own if the partner never set it up. Federate the partner into your identity provider, or issue the factor yourself, so the enforcement point is one you can audit.
The cost is real and is why this keeps not happening. Partners will object that case-bound lookup slows fieldwork. A per-account baseline produces false positives on the first day a task force stands up. Federation is a project with a hundred small agencies, each of which has one IT person. The workable sequence is to instrument first, because logging subject-level access breaks nothing, then set alert thresholds against a month of real data, then narrow scope for the roles whose real usage shows they never needed more.
If scoping the application is out of reach this quarter, an hourly per-session query cap at the gateway is the compensating control. It is crude, and it turns a full table pull into a few hundred rows and an alert.
What to check this week
- List every outside organization that holds a login to a system you own. If the list has to be assembled from tickets, that is the first finding.
- For each partner role, run the broadest query the role permits and count what comes back. Compare that number to what one user of that role needs.
- Confirm the access log records the subject of each lookup, not only the session. Run the query above against it.
- Confirm where the second factor is enforced. If the answer is "the partner's policy," it is not enforced on your system.
- Check whether per-account query volume is graphed anywhere anyone looks. A dashboard nobody opens is the same as no dashboard.
Ten days after discovery, FLHSMV has published nothing about how many records one Plant City login could reach. That silence may be the investigation. It may also be the answer.
North InfoSec runs AI-assisted penetration testing and security assessments, including chained testing that starts from one valid partner credential and measures what it can reach. northinfosec.com