Boston cut Flock Safety after its plate data became searchable nationwide

A configuration setting, not a breach

Boston's mayor announced in September 2026 that the city was ending its relationship with Flock Safety, the vendor behind its automated license-plate-reading network. According to a dev.to writeup that draws on UFD Tech's reporting, the decision was not triggered by a hack. It followed the discovery of a configuration setting that made Boston's plate-reader data searchable by police departments across the country, for purposes the city had never approved.

Flock's fixed cameras photograph every vehicle that passes and log the plate number, the timestamp and the location. Agencies that join the network can share that data with one another, and in Boston's case the default settings spread the city's data far more widely than city officials realized. Once the configuration was flagged, Flock closed the gap. But per the dev.to account, there was no audit trail showing who had already searched Boston's plates, and the underlying records had already aged out under the system's standard 30-day retention window. Residents learned about the exposure roughly seventeen months after it happened.

Cancelling the vendor didn't stop plate reading

The detail that received less attention, the dev.to writeup notes, is that the Boston Police Department had already installed 75 plate-reading cameras from other vendors, Motorola and Axon, before the Flock cancellation was even announced. Plate capture continued under different branding.

Public records, according to the same account, showed around 11,000 searches against the plate database over five months. Roughly half of those searches carried no case number at all, meaning there is no record of what investigation, if any, justified the lookup.

The failure mode survives a vendor swap

The dev.to piece argues that the core risk was never Flock specifically. A plate-reader network is only as trustworthy as every individual who holds a login: the system cannot tell a legitimate stolen-vehicle inquiry apart from an officer looking up where a former partner's car tends to appear. Nationally, it reports, hundreds of officers have been formally accused of running plate or database searches for personal reasons with no case attached. Swapping one vendor for another, or issuing a press release about a terminated contract, does not change any of that.

The writeup lists the questions worth asking when a city says it is ending a surveillance contract: whether the hardware actually came down or was simply relabeled, whether every search is tied to a mandatory case number in an audit log, how long data is retained and who can query it before it expires, and whether oversight is independent of the department running the cameras.

Why it matters

Boston is a concrete case study in how surveillance accountability fails in practice: a misconfiguration exposed data nationwide, the fix arrived with no accounting of prior access, a 30-day retention window erased the evidence before anyone could audit it, and a replacement network was quietly assembled from different hardware under the same operating model. The incentives stayed put while the vendor name changed.

For technical readers, the story also illustrates that in shared data systems, defaults are policy. Boston's exposure reportedly came not from an attacker but from settings the city did not know it was running, and the retention schedule guaranteed there would be nothing to inspect afterward. An audit regime that cannot reconstruct who queried what, and when, is not oversight but an assumption. As the dev.to piece suggests, a practical next step is checking whether your own city publishes plate-reader search logs in response to public-records requests; many departments do not, and that gap is where oversight tends to evaporate.