Tag Archives: tprm

Add FR to Flock: Another Meaning for TPRM

What happens when a third party proceeds to add FR to Flock? Another meaning for third party risk management.

I intentionally used abbreviations in my title for letter count purposes, so I should explain that “FR” means facial recognition, and “TPRM” is third-party risk management. The latter usually refers to managing data that third parties process for your company (or mismanaging it). But what if it meant that the third parties do something to your software that you refuse to do yourself?

Flock Safety and facial recognition

Take Flock Safety, a company that has its own controversies. But there are some things that Flock Safety will NOT do.

“No. Flock cameras do not use facial recognition.

“They are built to identify vehicle information, not personal biometric data.”

Add FR to Flock via VIDIZMO

But before you breathe a sigh of relief, remember that just because Flock Safety doesn’t incorporate facial recognition doesn’t mean that third parties can’t do it either. 404 Media:

“A company called VIDIZMO is advertising the capability to export footage from FlockOS to its own platforms that do facial recognition, behavior prediction, and racial and gender analysis on live camera feeds.”

This is not some great fault of Flock Safety, because ANY program that allows export (or a screenshot) can pass its data to some other program.

Any third party can add FR to Flock. (And this isn't my real license plate number.) Google Gemini.
Any third party can add FR to Flock. (And this isn’t my real license plate number.) Google Gemini.

I can take a screenshot of something that displays on a religious website and feed it into a porn generator. That’s not the religious website’s fault.

Oh, and just to confuse the issue: VIDIZMO advertises this capability, but doesn’t have it yet.

“VIDIZMO’s CEO, Nadeem Khan, told 404 Media on a video call that the company has not yet started running facial recognition tech on footage from Flock cameras, and that it has not actually built the specific tool that would export data from Flock’s system to its own platform.”

Add FR to Flock via Clearview AI

But VIDIZMO isn’t the only game in town. The DeFlock folks note that at least one jurisdiction has both Flock Safety and Clearview AI software.

“As WECT reported on August 10, 2026, in a July email to county leaders Sheriff Ed McMahon wrote that the county’s [Flock Safety] system does not use facial recognition, is not used for traffic enforcement, and is not a live surveillance system, collecting only what he called ‘limited’ vehicle information.”

But…

“The Sheriff’s Office…purchased Clearview AI — ‘Clearview Search PRO,’ $12,995 per year (plus a $500 setup fee), County Contract #24-0236 — procured through Carahsoft and set to auto-renew. Facial recognition is not something New Hanover might acquire; it is software the Sheriff’s Office already owns.“

At the same time, DeFlock makes it very clear that it has no evidence that the agency HAS linked the two software programs. Just that it COULD.

This fits within the realm of the possible, but not necessarily the realm of the probable.

The FBI Data Hack: Maybe Not an FBI Hack

So everyone’s talking about the FBI data hack, but they’re making assumptions about the FBI itself that may be unfounded.

The story is that ShinyHunters claims to have accessed data from FBIJobs.gov. Obviously whenever you apply for a job, you end up providing a lot of personally identifiable information. And sometimes the information can get REALLY personal.

According to Tech Insider, the FBI has now confirmed the hack occurred.

“According to reporting from PBS NewsHour and NBC News, the bureau said it is ‘aware of a cyber-criminal enterprise group claiming a compromise of the FBIJobs.gov portal and alleged impact to FBI employee personally identifiable information.'”

Aha, everyone says. Someone hacked the FBI!

But the FBI also said something else.

“The FBI added that ‘we are actively and aggressively investigating this matter and working closely with those third-party providers that support FBIJobs.gov to mitigate any and all risk.'”

This raises the possibility that the hackers didn’t get the FBI, but one of the “third-party providers.”

The FBI data hack may have been a hack of a third party. Google Gemini.
The FBI data hack may have been a hack of a third party. Google Gemini.

Kinda like how someone hacked Hertz information, but actually hacked the third-party provider IDScan.net.

Third party risk management (TPRM) is a critical part of your cybersecurity posture. You’d better make sure yours is robust before you’re the victim of a hack.

Are you a TPRM provider who implements solutions for identity, biometric, and technology firms? Or are you a firm who incorporates TPRM into your processes to protect customer data? Then I can help you communicate your solution to convince your customers of the safety of their data. Learn about Bredemarket at https://bredemarket.com/watch-book/.

Watch a 15-Second Pitch, Book a Free 30-Minute Meeting. Revised 10/28/2026.

The Incident

My 45-second video summary of recent Bredemarket blog posts. The posts discussed the hack at IDScan.net of over 153 million driver’s licenses and other data.

The Incident. Google Lyria. Public Domain.

Here are the three most important posts I’ve written:

Now I Can Say the Name IDScan.net (the 153+ million record hack)

I was reluctant to reveal the party involved in the massive hack of 153+ million driver’s licenses and other data.

But now the company, IDScan.net, has spoken.

And as I noted earlier this morning, many other firms must send out notifications now.

IDScan.net notification of a data security incident

(Original here.)

On or around September 1, 2026, IDScan.net received information indicating that certain data may have been accessed without authorization. Upon this discovery, we took immediate steps to secure our systems and engaged a team of third-party specialists to help determine the full nature and scope of the incident. This investigation is currently ongoing.

While the investigation is ongoing, IDScan.net has determined that an unauthorized third party may have accessed and/or copied certain customer information stored within their accounts on the IDScan.net cloud. The types of information contained within the affected data may include full names and driver’s license or other government-issued identification numbers.

Though full access to the information required payment, in an abundance of caution, we are notifying potentially impacted individuals of this incident and providing access to free credit monitoring and identity protection services. If you have questions about this incident or would like to enroll in the credit monitoring and identity protection services, please call 1-833-516-2980, Monday through Friday, between 8 AM and 8 PM ET, excluding holidays. You may also write to us at 8814 Veterans Memorial Blvd, Suite 3-124, Metairie, LA 70003.

Individuals are encouraged to remain vigilant against incidents of identity theft and fraud by reviewing credit reports and account statements for suspicious activity and to detect errors. Individuals may also place a fraud alert or credit freeze by contacting the credit reporting agencies: TransUnion 1-800-680-7289, P.O. Box 2000 Chester, PA 19016, transunion.com; Experian 1-888-397-3742, P.O. Box 9554 Allen, TX 75013, experian.com; Equifax 1-888-298-0045, P.O. Box 105069 Atlanta, GA 30348, equifax.com. Individuals can further educate themselves regarding identity theft, fraud alerts, credit freezes, and steps to protect their personal information by contacting the credit reporting bureaus, the Federal Trade Commission (“FTC”), or their state Attorney General. The FTC may be reached at 600 Pennsylvania Ave. NW, Washington, D.C. 20580; www.identitytheft.gov; 1-877-ID-THEFT (1-877-438-4338); and TTY: 1-866-653-4261.

In response to this incident, we immediately began an investigation and reviewed our policies and procedures related to data security. We are also cooperating with federal law enforcement on their investigation.

Breach Reporting For Financial Institutions, Including Car Dealers

(Update: Statement from IDScan.net. You heard it here last.)

I’ve talked about breach reporting a lot…and expect to talk about it more over the next few days.

Car dealers

But who has to report?

The Federal Trade Commission (FTC) is one of many agencies that regulate financial institutions.

Including one type of financial institution that we normally don’t think of as such.

A limousine with tinted windows in which one passenger is barely visible.
An automobile. Google Gemini.

From the FTC:

“The FTC’s Safeguards Rule, which dates back to 2003, requires financial institutions to maintain safeguards to protect customer information. The FTC issued the Rule to implement the requirements of the Gramm-Leach-Bliley Act, and it applies to financial institutions subject to the FTC’s authority.”

Go on…

“That includes most automobile dealers who finance or lease automobiles.”

The safeguards

So what safeguards do car dealers need to implement?

His private information leaked. Did the leaker perform required breach reporting?
The leak. Google Gemini.
  • Maintain a comprehensive written information security program that covers the customer information, including unauthorized access to the information. The program must cover any third-party service providers that can access the customer information, including anyone who bought or sold the data.
  • Create a written security incident response and recovery plan so that when things go wrong, you are prepared.
  • Update your information security program as necessary.

Mechanics of breach reporting

The most visible part of the response and recovery plan is breach reporting in accordance with federal law and state law.

Breach reporting requires notification of affected consumers.
Notifications. Google Gemini.

I previously outlined California breach reporting requirements:

“Under California SB 446, a firm must notify affected California residents within 30 calendar days of discovering or being alerted to the breach.”

Other states have their own notification requirements.

The third-party effect

And here’s where it gets interesting.

For the last few days, I’ve been waiting for a particular identity verification provider to report a breach of over 153 million driver’s licenses and other data.

But that firm will be just one of many firms that will be reporting. Many if not all companies that provided data to this identity verification provider will ALSO have to report.

Third party risk management, illustrated by a locked safe connected to a breached safe.
TPRM. Imagen 3.

Good old third-party risk management in a high-risk breach.

Expect a flood of notifications, possibly very soon.

What should you say in advance of breach reporting?

But breach reporting is not enough. Your firm, whether it’s a car dealer, an identity verification provider, or someone else, needs to proactively communicate how you handle breaches. And communicate this long before a breach occurs.

Why? To give your customers reassurance that if a breach happens, you’ll handle it.

Have you developed:

  • the strategy to explain how you will handle PII breaches?
  • the tactics to write these explanations for your content and your proposals?

If you haven’t, bring on an experienced identity, privacy, and product marketing consultant to help you with your strategy and tactics.

John E. Bredehoft in Bredemarket’s worldwide corporate headquarters in Ontario, California.

Bring on Bredemarket.

And book a free appointment to assess your needs.

Feel free to reshare using the “Share this” buttons below.

So Do We KNOW Which Identity Verification Company Was Hacked to Give Nexus the 153 Million Driver’s Licenses?

(Update: Statement from IDScan.net. You heard it here last.)

No, we don’t really KNOW yet.

If you missed the story about the 153-plus million Driver’s licenses on the dark web, see my post from yesterday.

Data Aggregation of Driver’s License Data Comes at a Cost (The Nexus Hack)
Bredemarket blog, September 3, 2026.

Specifically:

“The people behind Nexus claim the license images are coming from an active breach at “a major identity verification company” whose customers include multiple Fortune 500 companies.”

Of course, the Nexus hackers may be lying to misdirect anti-fraudsters and cover their tracks. Fraudsters are not trustworthy people.

But if the Nexus hackers are telling the truth about the source of the hacked driver’s license data, some identity verification company is going to be in very big trouble.

Now some of you are saying, “But John…we KNOW who the identity verification company is!”

  • Yes, I know that the Krebs on Security article stated that some of the hacked ID cards were for marijuana dispensaries, and that a particular named ID verification company does business with marijuana dispensaries.
  • And that some of the hacked data appears to have been from car rental agencies, and this same ID verification company does business with a very large car rental agency.
  • And the FBI opened an investigation in its office where this ID verification company happens to be headquartered.

So how come I’m not naming the company now?

Two words: Richard Jewell.

Richard Jewell, hero turned suspect turned hero.

He was falsely accused of the Atlanta Olympics bombing in 1996.

By August 2007 he was dead from complications from diabetes; he was only 44. His mother, who was caught in the same negative press onslaught, outlived him by over a decade.

So I’m waiting for more definitive information. Smoke isn’t enough.

Data Aggregation of Driver’s License Data Comes at a Cost (The Nexus Hack)

(Update: Statement from IDScan.net. You heard it here last.)

From Krebs on Security:

“A new identity theft service launched on the dark web this week is selling digital scans of more than 153 million drivers licenses from people in the United States and Canada….The service, dubbed Nexus, claims to have more than 153 million drivers licenses for people in the United States and Canada, as well as more than 10 million identification cards; more than three million travel documents and/or international IDs; and at least 579,000 medical cards.”

Now this isn’t a hack of a single state or province, since none has 153 million records.

But there are services that aggregate driver’s license data. The first one that came to mind is the American Association of Motor Vehicle Administrators, or AAMVA. Specifically, its Driver’s License Data Verification (DLDV) Service and its State-to-State (S2S) Verification Service.

But this doesn’t mean that AAMVA was hacked, since a number of third party entities can access the AAMVA data.

  • For example, the states themselves. If you apply for a new license in a participating state, it can check to make sure you don’t have an active license in another state. Having two driver’s licenses from two separate states is bad.
  • In addition, identity verification providers can access the AAMVA data. If you present “selfie plus ID” to verify your identity, the identity verification provider may not only confirm that the ID is real, but may also check with the issuing state or province to confirm it has a record of the license.

So with all these entities that can access the AAMVA data, you have a nice little third party risk management issue.

In fact:

“The people behind Nexus claim the license images are coming from an active breach at “a major identity verification company” whose customers include multiple Fortune 500 companies.”

Of course, the Nexus hackers may be lying to misdirect anti-fraudsters and cover their tracks. Fraudsters are not trustworthy people.

But if the Nexus hackers are telling the truth about the source of the hacked driver’s license data, some identity verification company is going to be in very big trouble.

Regardless, you can buy licenses of real people. Brian Krebs says that Pete Hesgeth’s license data is on the dark web. As is Krebs’ own license. And his mother’s.

No idea if my data is out there.

But 153 million people will be very interested in the source of the hack.

When, Not If: California’s Mandatory Protocol for Data Breaches

Words are funny things.

If you are asked what your California firm will do IF your data is breached, then you’re tempted to say that the question doesn’t apply because your firm’s data will NEVER be breached. After all you have multiple security certifications, which means your data is 100% protected…right?

Google Gemini.

Tell that to Cushman & Wakefield, The Moody Bible Institute of Chicago, Station Casinos, UCLA Health, or any of a myriad of firms that reported data breaches in accordance with California law. Or better still, check with the companies that failed to report data breaches under California law.

But if you are asked what your California firm will do WHEN your data is breached, then you will be forced to develop an action plan. Which is a good thing.

Six items in your data breach action plan

The first thing in your action plan should hopefully be obvious: secure the breach! Revoke compromised access credentials. Preserve digital evidence for forensic investigation.

Second, determine the damage. Was any unencrypted personally identifiable information (PII) or protected health information (PHI) leaked? Or pretty much the same thing: were any decryption keys leaked with encrypted data?

Third, notify.

  • Under California SB 446, a firm must notify affected California residents within 30 calendar days of discovering or being alerted to the breach.
  • The notice must be in plain language, formatted for high visibility (at least 10-point font), and titled explicitly: “Notice of Data Breach.”
  • The notice must include five mandated headings:  What Happened⁠, What Information Was Involved⁠, What We Are Doing⁠, What You Can Do⁠, and For More Information⁠.
  • If certain PII is breached, you must offer at least 12 months of free identity theft prevention/mitigation services and provide instructions on how to enroll.
Google Gemini.

Fourth, notify. You’re not done notifying yet. If the breach affects more than 500 California residents, the firm must electronically submit a sample copy of the notification letter (with PII redacted) to the California Attorney General’s portal within 15 calendar days of notifying individuals.

Fifth, notify. If PHI was breached, add the California Department of Public Health (CDPH) to your notification list.

Sixth, notify. If you manage third party data, notify the data owner. (And the data owner will need to perform all the notifications above. The fun of third-party risk management.)

Can Bredemarket help you prepare your action plan?

Yes.

I’m not a lawyer.

But I am a writer.

And I write processes, including privacy processes.

Talk to me.

Stop losing prospects! Use Bredemarket content for tech marketers

TPRM News I Missed From April

“Sydney, Australia — 21 April 2026—Protecht Group (“Protecht”), an Australian based global leader in governance, risk and compliance (GRC) solutions, today announced the acquisition of VISO TRUST, a US-based third-party risk management platform powered by artificial intelligence (AI). “

Source:

Protecht acquires leading AI-powered risk platform VISO TRUST

Third/Fourth Party Risk Management and Age Verification

Let’s say a bar wants to check the ages of its patrons, but does not want to use the patron’s physical ID card (in my country, usually a driver’s license).

But a bar cannot perform digital age verification on its own. The bar has to contract with some other entity that knows how to do this.

This freaks some people out…massively.

“New cybersecurity research indicates that one of the world’s leading age verification providers collects and shares highly sensitive personal data—including facial photos and device fingerprints—with third parties.”

The research, conducted by the Georgia Institute of Technology and UC Irvine, focused on one of the big age verification vendors, Yoti.

“The research team determined that the process Yoti uses to verify a person’s age broadcasts the person’s personal information to third- and fourth-party companies….

“According to the researchers, the data is…sent to credit card companies, IP geolocation services, and data brokers. The researchers found that the information being shared can be used to identify and track devices. For example, a single verification attempt may transmit a user’s facial image, IP address, and device fingerprint to credit card companies.”

Yet to my knowledge the researchers did not propose an alternative.

Other than having each entity develop its own age verification system. Perhaps someone like Meta could do that, but Frank’s Bar certainly couldn’t.

Age verification is not unique in terms of data sharing. Third Party and Fourth Party Risk Management vendors encounter these issues all the time. And yes, sometimes companies that have other companies’ data are hacked. That’s why they use TPRM in the first place.

Image source: GET Group NA, https://apps.apple.com/us/app/get-mobile-verify/id1501552424.

And don’t forget that if you don’t use digital age verification, you’re going to use physical age verification, where the guy behind the bar learns EVERYTHING about you. I don’t think that’s necessarily better.

It’s time to think through the consequences of abandoning technology.