Has Flock Been Hacked? What Their Security Blog Post Doesn't Say

Flock claims it has "never been hacked." A fact-check of their January 2026 blog post reveals semantic games, undisclosed offshore contractors, and CJIS compliance failures.

by H.C. van Pelt11 min read

Has Flock Been Hacked?” is the question the Flock Safety Blog asked itself today. The article is a transparent[1] attempt to get ahead of the SEO game. It repeats the same tired points, and so will this fact-check, but such is the nature of fighting misinformation and disinformation on the Internet.

The executive summary:

Flock Claim Reality Source
“Cloud platform has never been compromised” Scoped to exclude hardware vulnerabilities, network exposures, contractor access, and access control abuse Flock blog
“No customer data accessed or exfiltrated” “Customer data” contractually excludes raw footage—the same footage publicly streamed from Cedar Rapids Contract language
“Customers own and control their data” Contract grants Flock “non-exclusive, royalty-free, irrevocable, worldwide license” to use customer data Standard contract
“No centralized database” Shared SaaS infrastructure; network-wide hot lists enable cross-jurisdictional queries Network analysis
“Registered vulnerabilities with MITRE” Only 4 CVEs registered; 50+ findings in Gaines report unaddressed Gaines report
“Worked with researcher throughout study” Researcher confirms Flock has not confirmed remediation of any reported issues Gaines report
Offshore contractors Not mentioned Wired, Upwork portal
CJIS compliance Not mentioned; devices lack required encryption Gaines report
  • Flock’s “never been hacked” claim is scoped to exclude hardware, contractors, and access abuse
  • Security vulnerabilities reported in February 2025 remain unpatched as of November 2025
  • Offshore Upwork contractors review surveillance footage without disclosed vetting
  • CJIS-required encryption is absent from Flock devices
  • No evidence of a Flock data breach notification to Iowa agencies despite documented vulnerabilities and foreign contractor access.

Flock Security Vulnerabilities: Still Unpatched a Year Later

Flock writes that “the theoretical vulnerabilities described were highly technical and would have required physical access.” It does not write that these “theoretical vulnerabilities” no longer exist.

The issues were reported to Flock in February 2025. In November 2025, they were confirmed to still exist.

Flock writes in the past tense, but gives no indication that use of this tense is warranted.

A typical “trust us, we’re fine” security blog post follows a predictable pattern, to the point where I’m certain there is a CISO-central where you can download form letters:

  • We were made aware of a vulnerability on [date].
  • We worked with researcher A to develop a fix that we rolled out [shortly after].
  • We carefully examined our logs and determined no data was compromised. (Alt: We determined that a limited set of data may have been accessed. Affected customers were notified in a separate email).
  • No action is required. (Alt: We recommend that you take X action immediately. We have disabled Y until you do).

Instead, nine months after Jon Gaines “worked with Flock throughout the study” (according to Flock’s blog post), his report states, “the vendor has not confirmed whether any of the reported issues have been remediated or are planned for remediation.”

The only action Flock has taken is to downplay the severity and exaggerate the complexity for the better part of a year.

Flock’s CJIS Compliance Failures

There are several (well… many) issues with Flock’s compliance issues, but the most straightforward one is that the vulnerabilities Flock discusses in this post show that Flock devices are not encrypted.

Encryption is a hard requirement for CJISSECPOL.

Who Can Access Flock Safety License Plate Data?

While its overseas workers may access the data for other reasons, Flock states in its blog post that “Flock employees do not access customer data except in tightly controlled, audited circumstances for support or maintenance.”

Critically, the company does not define what those “tightly controlled, audited circumstances” look like, who validates those controls, or who performs the audits. We can only assume it’s Flock doing all of this in secret.

However, in its contract, Flock defines circumstances other than “support or maintenance” where its employees may access and disseminate information, including when Flock has a “good faith belief” that doing so is necessary for basically any reason.

Flock Offshore Contractors, Background Checks, and Foreign Data Access

We know Flock images and audio are reviewed by foreign Upwork contractors. Flock has not publicly acknowledged or commented on that fact. Flock hid the evidence after Wired and 404Media reached out for comment.

As of January 6, 2026, Flock’s Upwork Enterprise Portal is still online.

After national media reported on these contractors who are reviewing images and audio files, Flock did not respond at all.

It did not put out a statement that its foreign contractors undergo rigorous vetting or that the data collected by 250,000+ devices is not available to foreign actors.

It is also unclear if Flock considers Upwork contractors on the other side of the globe to be operating under “tightly controlled, audited circumstances.”

Flock Data Retention and Deletion Questions

Based on my experience, “what happens after the retention period?” question is an actual “Frequently Asked Question.” To my knowledge, Flock has not answered it beyond “data is automatically deleted” (generally passively voiced).

The process for deletions, and, equally importantly, the process for validating whether deletions are complete and irreversible, remains a mystery to this day.

This is a critical question because the storage solution the company uses, AWS S3, offers versioning and “soft deletes,” a feature where a “deletion marker” is stored alongside the actual file (possibly in low-cost archival storage).

This makes the file appear deleted to everyone, including the software, except S3-administrators for whom restoring the file is a matter of either removing the marker, or copying the file while ignoring the marker.

Of course, this is in addition to the contract granting Flock the “non-exclusive, royalty-free, irrevocable, worldwide license to use the Customer Data,” for which Flock has not even begun answering the question.

Flock Breach Notification: Iowa Case Study

A public records request to the Iowa Department of Public Safety, which is responsible for overseeing CJISSECPOL, indicates that neither Flock, nor any of its Iowa customers, made the mandatory disclosures following the February 2025 vulnerability findings, or the findings that overseas workers have access.

It is likely no different in other jurisdictions.

“Has Flock Been Hacked?” — What They’re Actually Saying

This article was a trip. It comes on the heels of a December 8, 2025 mass email in which Flock’s Head Solutioneer, Chris Colwell, defensively states that Flock has never been hacked and that the information published on “a third-party website [that] began aggregating search information” was instead obtained via public record requests.

Maybe Colwell got the “Has Flock Been Hacked?” question via e-mail. Maybe he didn’t. Either way, it’s oddly defensive posturing for a company whose CEO sends out mass emails saying it “adheres to the highest security standards, including: NDAA, SOC2 (Type II), SOC3, ISO 27001, HECVAT, [and] FERPA.”

Some of those aren’t even security standards, as I discussed in a previous post.

How Flock Defines “Hacked” and “Breach”

Flock’s cloud infrastructure has never been compromised. There has never been an incident in which customer data was accessed or exfiltrated by an attacker. This is not a matter of semantics or technical spin; it reflects Flock’s actual security record since its inception.

Immediately, Flock’s statements are limited to the “cloud platform.” This excludes:

Industry standards consider a “breach” or a “compromise” to be any incident where an unauthorized party has access, when data is disclosed without authorization, or when data control is lost. Flock’s definition is limited to “customer data was accessed or exfiltrated.”

This narrow definition of “hacking” excludes:

  • Authorized access later deemed improper (rogue employee, abusive search).
  • Data shared under coerced or misunderstood “consent.”
  • Access by contractors they failed to disclose.
  • Exploitation of legitimate credentials.

Flock’s “Customer Data” Definition Excludes Footage

“Customer data” appears to be an attempt at contractual finagling. If you’ve watched Benn Jordan’s video you know that Benn was able to view a live feed of actual cameras being used to support real-life operations.

This is the current definition of “customer data”:

“Customer Data” means the images, audio and/or video segments made available to Customer through the Web Interface in connection with the Flock Services, together with the metadata … For clarity, Customer Data does not include the underlying raw Footage captured by the Flock Hardware

By that definition, unauthorized persons downloading footage is not a “breach” or “access to customer data” because “customer data” does not include footage.

There was still a public Internet livestream of a man being hauled off in an ambulance.

Shortly before Flock aired that livestream, Cedar Rapids indicated to the ACLU of Iowa and University of Iowa researchers that its Flock contract has different language:

“Customer Data” means the data, media, and content provided by Customer through the Services. For the avoidance of doubt, the Customer Data will include the Footage.

Under Flock’s definition, the public exposure of a man being loaded into an ambulance was not a “breach” because raw footage isn’t “customer data.” Under Cedar Rapids’s contract, it was. Flock gets to claim a clean security record by choosing which definition applies after the fact.

Flock further muddies the waters in its blog post when it writes “Every Flock customer, whether a city, county, law enforcement agency, neighborhood, school, or business, retains full ownership and control of the data collected on their behalf.”

These statements can’t all be true at the same time. It doesn’t matter to Flock because Google’s AI won’t pick up on it. Poisoning the SEO-well with corporate disinformation is a business decision.

Flock Data Types: Strategic Obfuscation

Flock does not maintain a centralized database of license plate reader data across customers. We do not sell or monetize vehicle data, and we do not share customer data without the customer’s explicit authorization.

In two sentences, no fewer than three types of data are introduced:

  • License plate reader data
  • Vehicle data
  • Customer data

To know whether the statement could potentially be true requires knowing the definitions of these terms.

“We do not sell or monetize vehicle data” or “Flock does not maintain a centralized database of license plate reader data across customers” certainly do not sound true, but there is undoubtedly a reason why the company chose to distinguish between “license plate reader data,” “vehicle data,” and “customer data” all in one paragraph. And it’s not “for clarity.”

Perhaps the most baffling statement in the whole post is this one:

LPRs do not capture point-in-time images of vehicles on public roadways

I’m sure this too depends on some obscure, unspecified definition of “point-in-time image.” Maybe it means that you can’t tell the Flock system “find me a picture of a car with plate 739APD at 10:45am last Saturday” because you can only tell it “give me a 30-day location history for plate 739APD.”

Who knows. Even ardent Flock-fans can see that this statement is, at best, grossly misleading.

The important thing is that Flock asked itself “Has Flock Been Hacked?” and then proceeded to dodge the question as though it were participating in a Senate confirmation hearing rather than writing corporate fluff on its own blog.

What Flock Safety Should Disclose

First, CJISSECPOL requires compliance documentation to be submitted to the state’s CSA and the FBI. For security vulnerabilities, this includes mitigation plans and/or compensatory controls. This mandatory compliance documentation is public record. Disclose it.

Second, some security vulnerabilities require additional disclosure. The complete lack of encryption, for example, is fundamentally incompatible with CJISSECPOL, which requires using a NIST-validated encryption module. Name the modules.

Prove, or better yet, have an independent third party audit, AWS S3 configurations to confirm that buckets are unversioned, and there are no “soft deletes.”

Release the CVE numbers. Flock claims it “registered relevant vulnerabilities with the National Vulnerability CVE database via MITRE.” If true, those identifiers are public. Name them. If this set is limited to the four issues previously registered, then Flock’s position is that the remaining 50+ findings in Jon Gaines’ report are not “relevant.” This is a concerning attitude when it comes to security.

Disclosing public compliance records and confirming which vulnerabilities have been patched, by tracking them in a public vulnerability database or otherwise, does a lot more than writing an SEO-optimized blog post that relies purely on semantics and technical spin to say nothing of value.

Relying on security through obscurity is its own documented security vulnerability.

Relying on security through denial is even worse.


  1. It is a rare occurrence where I accuse Flock of transparency. ↩︎