BlueLeaks: one small web host, hundreds of agencies’ files

The week

On Friday, June 19, 2020, a transparency group called Distributed Denial of Secrets published a large collection of files from US law enforcement agencies and fusion centers. It called the collection BlueLeaks. The release came less than four weeks after the killing in Minneapolis that set off nationwide protests over policing, and those protests were still under way.

Fusion centers are hubs, usually run by states or large cities, where police, federal agencies and other partners pool and share information about crime and threats. They send out bulletins, collect tips from the public and other agencies, and help connect dots that no single department would see on its own. Sharing is the reason they exist.

Most of them grew up in the years after the September 11 attacks. The Department of Homeland Security recognizes about 80 across the country and supports them with grants, training and staff. They are owned and run by state and local governments, though, not by federal agencies. Each makes its own choices about technology, contracts and suppliers, and many of those choices are small ones made on modest budgets.

The scale of the leak was striking. The group said the archive covered more than 200 police departments, fusion centers and law enforcement training and support organizations, and ran to about 269 gigabytes. A gigabyte is roughly the size of a few hundred photos or several thousand documents, so the total amounted to a vast archive.

According to the National Fusion Center Association, as reported by KrebsOnSecurity, the files spanned nearly 24 years, from August 1996 to the day of the release. They included names, email addresses and phone numbers, documents, images, video, spreadsheets, and emails with their attachments. The association noted that some files held bank routing and account numbers, other personal information and images of suspects taken from requests for information. It was the kind of detail that can put people at risk if it reaches the wrong hands.

It had not come from hundreds of separate break-ins. An internal analysis by the association, dated June 20, traced the data to a breach of a single company, Netsential. The Houston web development firm built and hosted websites and portals for many fusion centers and law enforcement organizations. A portal, in this sense, is a password-protected website where members log in to read and download shared material.

The association’s analysis also suggested how it had happened. In its assessment, an intruder had likely used a compromised Netsential customer account and the platform’s upload feature to introduce malicious content. That foothold then allowed data belonging to other Netsential customers to be taken. One member’s login had been the doorway to everyone’s files.

For member agencies, the practical questions began at once. Each had to work out whether its own site was among those Netsential hosted, what it had posted there over the years, and which of its staff held logins. Agencies without an inventory of their own uploads had to reconstruct one from email and memory. Many learned the outline of their exposure from the same reporting the public was reading, rather than from the vendor.

The response moved fast where it could. On June 23, Twitter permanently suspended the group’s account for violating its policy on distributing hacked materials, and it blocked links to the group’s website. Those steps slowed the spread of links. They could not recall the files, which remained available for download.

One small supplier had, in effect, become the common back room for a large slice of the country’s law enforcement information sharing. When its systems were compromised, everyone’s files went out the same door.

Agencies spent the week assessing what had been exposed, as protests over policing continued nationwide. It was an exceptionally difficult moment to be working out which officers’ details, which victims’ names and which tipsters’ identities had just become public. Reporters, meanwhile, began reading the archive for what it showed about how fusion centers had tracked the protests themselves.

What leaders in government and well beyond it now had to explain was how a risk of that size had gone unnoticed by every organization that shared it.

Fusion centers and law enforcement associations share information by design. Many used web portals built and hosted by small specialist firms, because those firms understood the community and were affordable. Each agency assessed its own modest contract. Nobody assessed the platform as a whole.

BlueLeaks exposed three risks that existed only at that level. They were the concentration of many agencies’ data with one small vendor, the accumulation of years of sensitive material that nobody needed online, and an access model built for wide sharing. Each needs a different remedy, and each needs an owner who sees across agencies.

The article first explains why the arrangement made sense, because the risks grew out of sensible decisions. It then takes the three risks in turn and follows one member agency through a breach. It ends with the governance gap beneath all three, what it costs, and a short test for any shared platform.

Why agencies hand their portals to small firms

Take a regional association of police departments. Its members want to share wanted notices, officer safety alerts, training materials and intelligence bulletins. Building and running a secure website is not their core skill. So the association hires a small web firm that already serves similar groups. The firm builds a portal, hosts it on its own servers, creates logins for members and keeps it running for a modest annual fee.

That arrangement makes a lot of sense. The firm understands the community’s needs. It can reuse the same software for many clients, which keeps prices low. Members get a working platform without hiring developers. Over time, the same firm might end up running portals for dozens or hundreds of organizations, all on shared infrastructure, meaning the same servers, the same software and often the same administrator accounts.

How the money and the paperwork flow

Funding shapes these choices. Fusion centers and many regional associations rely partly on federal homeland security grants, alongside state and local budgets. Grant money tends to arrive in project-sized pieces. A portal gets built in one grant cycle and then maintained from whatever operating budget is left.

Procurement rules reinforce the pattern. Most procurement codes, federal, state and local, have a simplified path for small purchases. A hosting contract worth a few thousand dollars a year often qualifies. It may get a quote or two and a short approval rather than a formal security review. The rules were written to save effort on low-value buying, and a web portal looks low-value on an invoice.

Renewals then run on autopilot. Once a portal works, nobody wants to move hundreds of users and years of content to a new supplier. The contract renews each year with little scrutiny, while the content and the user list keep growing. The risk grows with them; the price does not, so nothing in the budget process flags it.

What shared hosting means technically

Shared hosting works like a self-storage facility. Each tenant rents a small unit and checks that its own padlock is sturdy. Nobody asks about the security of the building’s main gate, the master keys or the night guard. If a thief gets past the front office, every unit is exposed at once, and each tenant’s careful padlock is beside the point.

In software terms, the building has several shared parts. There is usually one application codebase serving every customer’s site, with branding and content swapped per tenant. Customer data may sit in separate databases, but those databases often run on the same server under the same service account. Vendor staff use one administrative console to manage every site. Features such as file upload are built once and used by all.

Each shared part is a path from one tenant to another. A flaw in the common code affects every site at once. An upload feature that accepts the wrong kind of file can let an attacker plant a script that runs on the server itself. Once code runs on a shared server, the boundaries between tenants depend entirely on how carefully the vendor separated them, which few customers ever check.

BlueLeaks revealed exactly that structure. By the association’s account, the entry point was one customer’s account and one shared feature. The risk lived in the building, and no single contract described it.

Hundreds of agencies, one small vendor

A single compromised vendor exposed data from hundreds of organizations. Each agency, looking only at its own contract, saw a website or a portal at a modest price. The aggregate risk existed only across the vendor’s customer base, and no customer was positioned to see it. Procurement rules often reinforce this blind spot: a small contract gets a light review, regardless of how sensitive the data is or how many other organizations share the same supplier.

Small vendors are not inherently less secure, but they often lack dedicated security staff, independent assessments and the ability to detect and contain a capable intruder. An independent assessment is a review by a qualified outside party that checks a provider’s security controls against a recognized standard, rather than taking the provider’s word for it.

The remedy is to set minimum security requirements for any vendor hosting sensitive information, scaled to the data rather than the contract value. Agencies can prefer hosting arrangements that have been independently assessed. Information-sharing networks can assess common vendors once on behalf of all members, which is more searching than each member sending the same questionnaire. A hundred agencies each mailing a checklist produces a hundred shallow answers; one joint review can actually look under the hood.

What a joint assessment should cover

A joint review is only as good as its scope. For a multi-tenant portal, the questions that matter most are about the shared parts, not the paperwork. Five areas deserve the most time:

• Tenant separation. How customer data is kept apart, whether one tenant’s account can ever reach another’s files, and whether that has been tested by someone trying to break it.
• Risky features. How file uploads, search and export are restricted, since these are the features attackers abuse to plant code or pull data in bulk.
• Administrative access. Who at the vendor holds master credentials, whether those logins require a second factor, and whether their use is logged somewhere the administrators cannot erase.
• Patching and change. How quickly the vendor applies security fixes to its software and the components it relies on, and who checks that it did.
• Detection and response. Whether anyone watches for intrusions, how long logs are kept, and what the vendor will do in the first day of an incident.

The evidence for each should be something an outsider can check. That might be an independent audit report, a recent penetration test with its fixes tracked to closure, or a cloud authorization under a recognized program. A signed questionnaire is a statement of intent; it is weak evidence on its own.

Contract terms that matter on a shared platform

Contracts with shared-platform vendors should require prompt notice of any security incident affecting any customer, whether or not it is the contracting agency. On a shared platform, one customer’s breach is everyone’s. Agencies should also know where their data is hosted, which vendor staff can reach it, and whether backups and old copies exist elsewhere. Those questions are cheap to ask at renewal and very hard to answer after a leak.

A few other terms earn their place. A right to receive assessment results, even if not a right to audit in person. A requirement that the vendor return or destroy data at the end of the contract and certify that it did. A list of the vendor’s own suppliers, such as the hosting company under its servers, with the same obligations passed down to them.

Where vendor staff will have access to criminal justice information, the FBI’s CJIS Security Policy already requires private contractors to sign its Security Addendum and meet its requirements. Agencies should check with their CJIS systems officer and counsel whether a portal falls in that scope. Where it does not, the addendum is still a useful model for what to ask.

Helping small vendors improve

Small vendors also need room to improve. A requirement for independent assessment or multi-factor authentication may cost a three-person firm more than a year’s contract value from any single agency. Multi-factor authentication means requiring a second proof of identity, such as a code on a phone, on top of a password. It is one of the most effective protections available and one of the first things a stretched small firm may lack.

Members acting together can fund those improvements, phase them in, or move the platform to an assessed hosting environment while keeping the vendor’s domain expertise. Treating the vendor as a shared asset that members invest in tends to produce better security than treating it as a supplier each member pressures separately. Members that demand improvements without funding them usually get questionnaires and paperwork back rather than better security.

The case for staying small, and its limits

The strongest objection deserves an answer. Large, heavily assessed providers get breached too, and when they do the damage can be wider still. Moving every portal to a few big platforms would replace hundreds of small concentrations with a handful of enormous ones. Small specialist firms also bring something hard to buy: an understanding of how investigators and analysts actually work.

That objection is right about size and wrong about the remedy. The argument here is not big versus small. It is that assessment effort should follow the total sensitivity of the data a platform holds and the number of organizations that depend on it. A small vendor can meet that bar with help. A large one can fail it. What nobody can afford is a review sized to one member’s invoice.

Years of files nobody needed online

The leaked material spanned many years. Bulletins and reports that had long served their purpose remained online, with attachments containing personal information about suspects, victims, officers and people who had sent tips. Information-sharing portals accumulate because publishing is a routine task and deletion is nobody’s job.

This is a near-universal pattern, not a law enforcement quirk. Shared drives, intranets, email systems and collaboration tools all grow the same way. Adding something is easy and someone is usually asking for it. Removing something feels risky and nobody is asking for it. Over a decade, the result is a large, mostly forgotten archive on systems that are designed to be reached over the internet.

Retention rules apply here as they do to any record. A retention rule simply says how long a type of record must be kept, and what happens to it afterward. Agencies should define how long shared material stays available online, then archive or delete it on schedule. A bulletin with operational value for 90 days does not need to stay on an internet-facing server for ten years.

Personal data should stay out of broad distribution products unless the purpose requires it. Where it is required, it can go in a restricted attachment with its own shorter retention. Data that is no longer online cannot leak from a web server, and a portal holding one year of material exposes far less than one holding a decade.

Taking files offline is different from destroying records

Records officers often resist this work, and for a real reason. State and local records laws set minimum periods for keeping many kinds of government records. Public records requests, litigation holds and investigations can all require an agency to produce old material. Deleting a bulletin that the law requires the agency to keep is its own problem.

The answer is to separate two decisions. How long a record must be kept is a records question. How long it must stay on an internet-facing portal is a security question. A bulletin can come off the portal after its operational life and still be kept, for the full legal period, in an offline or restricted archive. Agencies that bring their records officer and their security lead into the same room usually find the two goals fit together.

Some intelligence material carries its own rules. Criminal intelligence systems operated with funds from certain Justice Department grant programs are subject to 28 CFR Part 23. Among other things, it requires that information be reviewed and either validated or purged within a retention period of no more than five years. Whether a given portal or bulletin falls under it is a question for counsel, since much situational material does not. Where it applies, a decade of unreviewed intelligence on a web server is hard to square with the rule.

Who owns a bulletin once it is shared

Retention also stalls on ownership. The agency that wrote a bulletin regards the portal as the host’s system. The host regards the content as the originating agency’s property and will not remove it without permission. The vendor removes nothing unless told. Each party has a reason to leave the file where it is.

A sound rule assigns the decision to the originator, sets a default expiry that applies unless the originator renews, and gives the platform owner authority to enforce the default. Expiry by default reverses the burden. Someone then has to act to keep a file online, rather than someone having to act to take it down.

Someone has to do the work. Assigning each publishing unit responsibility for reviewing its own content annually, with a report to the platform owner, turns retention from a policy into a practice.

One fusion center’s retention rule

Suppose a state fusion center publishes about a thousand bulletins a year. Under its old habits, all of them stayed on the portal indefinitely, many with names and photos attached. Under a new policy, routine bulletins come down after a set period and move to an offline archive. Names and identifying details go into a separate, restricted attachment that only specific roles can open and that expires sooner. Each unit certifies once a year that its content meets the rule. If that portal were breached the next day, the exposure would be one year of mostly non-personal material rather than a decade of names, addresses and tips.

The trade-off is real but small. Analysts lose the convenience of searching ten years of bulletins in one place. They can still request archived material, with a short delay and a record of who asked. Most find that the old material was rarely used, which is why nobody had noticed it was still there.

Logins built for wide sharing

Information-sharing portals typically serve many users across many agencies. Accounts persist after people change roles or leave, because the portal operator cannot see personnel changes at member agencies. Authentication strength, account review and logging vary by portal. When sensitive material is shared broadly, the weakest account and the least monitored server set the exposure.

BlueLeaks made that point concrete. By the association’s account, the intrusion began with one compromised customer account. Every additional account on a shared platform is another key to the building, and on most portals nobody counts the keys.

Where a portal carries criminal justice information as defined by the FBI’s CJIS Security Policy, that policy sets requirements for access control, authentication and auditing. CJIS, the FBI’s Criminal Justice Information Services division, sets the rules that agencies must follow to access national criminal justice data, such as criminal histories. Agencies should confirm with counsel and their CJIS systems officer whether a given portal is in scope. Not all fusion center material is CJIS information, but treating sensitive shared material to a comparable standard is sound practice.

Let the home agency control the account

The root problem is that a portal keeps its own list of users and passwords, separate from each member agency’s staff records. When an officer retires, the department disables the officer’s email account the same day. The portal account lives on, because nobody told the portal.

Federated sign-in fixes much of this. The member agency’s own identity system vouches for its users, and the portal accepts that assertion instead of keeping its own password. When the agency disables an account at home, portal access ends with it. Federal portals such as the FBI’s Law Enforcement Enterprise Portal support this kind of federated access for participating agencies. Smaller platforms can adopt the same standards, though small agencies without a modern identity system may need a fallback.

Federation does not remove the need for review. Regular account recertification, with each member agency confirming which of its staff still need access, is a simple control many portals lacked. Once a year the portal sends each agency a list of its users, and the agency confirms or removes each one. Accounts that nobody claims are disabled.

Logs that answer the questions an investigation asks

Logging that records who downloaded what, retained long enough to investigate, is the other half. Without it, agencies cannot tell which documents an intruder actually took, and so cannot tell whom they need to warn.

Useful logs record sign-ins and failures, every document viewed or downloaded, every file uploaded, and every administrative change. They are copied off the server as they are written, so an intruder with control of the server cannot erase them. The CJIS Security Policy, for systems in its scope, requires audit records to be kept for at least a year. For a portal that holds years of material, a year is a floor rather than a target.

Logs are only useful if something reads them. A simple rule, such as an alert when one account downloads far more than its usual volume, would catch the bulk export that a breach like this involves. That kind of alert costs little to run and is exactly what a small vendor without a security team will not have built unless asked.

The friction objection

Officers and analysts push back on stronger sign-in, and their objection has substance. A detective on a night shift who needs a bulletin now does not want to hunt for a code. Shared workstations in dispatch centers and patrol cars complicate device-based methods.

The answer is to match the method to the setting, not to drop it. Hardware keys, phone prompts and certificate-based sign-in each suit different workplaces. A second factor at the start of a shift, rather than at every page, keeps friction low. The cost of a few seconds per login is small next to the cost of an account that a stranger can use for months.

Inside one member agency after the breach

Follow a single member agency through the breach of a shared platform it relies on, and the value of each of the three controls becomes clear. Say a city police department in a state information-sharing network learns from the news that the network’s portal vendor has been compromised.

The first question is simply what of the department’s material was on there. Without its own inventory, the department has to ask the vendor, which is overwhelmed by calls from every other member. Days pass. The department’s staff begin searching their own email for anything they ever uploaded, and find they cannot be sure.

The second question is who is affected. If the portal held years of bulletins with names attached, the department now has to identify officers, victims, witnesses and tipsters who might be exposed, and decide whom to warn and how. Every year of retained material multiplies that work. A department whose content had been trimmed to a short window has a manageable list. One whose content stretched back a decade has a project.

The third question is what the intruder actually took. If the portal kept detailed download logs, investigators can narrow it down. If it did not, the department has to assume the worst and treat everything as exposed. That assumption drives cost: more notifications, more protective steps for officers and witnesses, more legal review.

The fourth question is whose accounts were used. If the intruder logged in with an old account belonging to someone who left years ago, the department learns that its access list was never cleaned up. That is an uncomfortable finding to explain to a city council.

The first two weeks, in order

The work has a natural sequence. In the first days, the department confirms what it can, freezes portal uploads, and resets any credentials its staff reused elsewhere. It names one person to deal with the vendor and the network, so that ten people are not asking the same questions.

Next comes triage of the people at risk. Officers whose home addresses or family details appear get priority, along with confidential informants and witnesses in active cases. Some will need practical protection, such as removal of personal details from data broker sites or changes to case handling. Prosecutors may need to know which cases could be affected.

Notification follows, and it is less simple than it sounds. State breach notification laws differ in whether and how they cover government agencies and which data types trigger a duty. Bank account numbers, which the association found in some files, often do trigger one. Counsel should map each data type to each state’s rules before letters go out, because a network that spans states may face several regimes at once.

Meanwhile, the department’s leaders face the public, the press and their own officers. They are answering for a system they did not run, built by a vendor they barely knew, holding data they had forgotten was there. The cost lands on them regardless.

Each of the three controls shortens this list of painful questions. A vendor assessed jointly is less likely to be breached. A short retention window shrinks what can be exposed. Clean accounts and good logs turn guesswork into facts. All three cost far less than responding to a breach like this one.

The governance gap underneath all three

All three risks share a governance gap. Individual agencies owned their contracts, associations owned the community and vendors owned the infrastructure. Everyone owned a piece; nobody owned the whole. Governance means deciding who is accountable for what, with what authority and what money.

Agencies should insist that each shared platform has an accountable owner with authority to set security standards, funding to check them, and a mandate written into the agreements among members. Without authority, the owner can only make suggestions. Without funding, standards stay on paper. Without a written mandate, the role fades when the person who championed it moves on.

Three ways to give a platform an owner

Networks have broadly three options, each with a cost. The first is to make the association itself the owner, funded by member dues set high enough to pay for assessment and oversight. That keeps control with the community but asks a volunteer-led body to act like a security function.

The second is to name a lead agency, usually a state fusion center or a state police agency, to host or contract for the platform on everyone’s behalf. That brings a real security team and procurement weight. It also means smaller members depend on a larger partner’s priorities and budget cycle.

The third is to move sharing onto an existing government platform, such as the FBI’s Law Enforcement Enterprise Portal or the Department of Homeland Security’s Homeland Security Information Network. Those platforms already carry federal security requirements. They may lack the local features members valued, and they shift the dependency to a federal operator rather than removing it.

Any of the three can work. The failure mode is the fourth option that BlueLeaks illustrated: no choice at all, so the vendor becomes the owner by default.

What the members’ agreement should say

Whichever model is chosen, the members’ written agreement should cover a short list. It names the owner and its authority to set and enforce standards. It sets how security is funded and what happens when a member does not pay. It assigns retention decisions and default expiry. It states each member’s duty to recertify its users. It defines who leads an incident response and who speaks publicly. A page or two is enough; what matters is that it exists and survives a change of leadership.

The same gap in banks and health systems

The same pattern exists well beyond law enforcement, in shared portals for emergency management, public health reporting and grant administration. It exists in the private sector too: industry consortiums that share fraud data, hospital networks that share patient referral portals, franchise systems where every location logs into the same supplier’s software. Wherever many organizations rely on one platform, the risk sits at a level that no single contract describes.

Some sectors have more formal tools for it. Banks work under supervisory expectations for managing third-party relationships, and examiners ask about concentration in critical providers. Health information exchanges that handle patient data for HIPAA covered entities typically operate as business associates, under contracts that set security duties. Those frameworks help, but they still tend to work one contract at a time. The shared-platform view has to be added on top.

What a leak costs, and what a governed platform has

For a public agency, the costs of a leak like BlueLeaks are broad. Officers and their families may face harassment. Victims and witnesses may be exposed. People who submitted tips may be less willing to do so again. Investigations can be compromised. Legislators, auditors and the press will ask how it happened and who was responsible, and the answer “we each had a small contract” satisfies none of them. Public trust, already fragile in a difficult period, takes a further hit.

A leak of this kind also exposes the work itself, beyond the people named in it. Bulletins show what agencies were watching and how they described it. When those documents become public during a political crisis, the debate shifts from the breach to the content. Agencies then have to defend their practices in public with no chance to explain context first. That exposure is harder to measure than a notification bill and often lasts longer.

Measures a council or board can track

Elected officials and boards rarely see security metrics for shared platforms, because no single agency reports them. A small set would change that. They include the number of shared platforms the agency relies on and the date each was last independently assessed. They include the share of each platform’s content older than its retention rule, and the share of accounts recertified in the last year. They include whether download logs exist and how far back they go. Each is a number an owner can produce in an afternoon, and each would have looked alarming on the Netsential platforms before June 2020.

A well-governed shared platform usually has five things:

• A named owner, with authority and a budget, accountable for security across all members.
• Security requirements set by the sensitivity of the data, not the size of any one contract, and checked through a joint independent assessment.
• Contract terms requiring the vendor to notify every customer of any incident affecting any customer.
• A clear retention schedule, enforced by annual reviews, with personal data kept to restricted, short-lived attachments.
• Strong login protection, regular recertification of users by each member agency, and download logs kept long enough to investigate.

BlueLeaks showed the opposite habits at work. Agencies judged risk by contract size and assumed a specialist vendor must be secure because it knew the community. Content stayed online forever, and accounts outlived the jobs they were created for. Each party assumed that someone else (the association, the vendor or another member) was looking at the whole picture.

Shared portals need an owner, a retention rule and access reviews

1. Which shared portals do we use to exchange sensitive information, who runs each one, and how many other organizations sit on the same vendor and infrastructure?
2. Are our security requirements for each vendor based on the sensitivity of the data or on the value of our contract, and would the vendor tell us about an incident affecting another customer on the same platform?
3. How long does our material stay online, who is responsible for taking it down, and does personal information about officers, victims or tipsters appear in it when it need not?
4. When did we last confirm which of our staff still need access to each portal, and could we tell from logs exactly which documents an intruder downloaded?
5. Who is the accountable owner of each shared platform, and is that role written into our agreements with the other members?

If several of these questions lead to “we assumed someone else handled that,” the platform has no owner.

The questions are deliberately plain. A chief of police, a county administrator or a bank’s chief risk officer can ask them of any shared platform without technical help. The answers, and how long it takes to get them, show whether anyone is looking at the whole.

With hindsight

German authorities seized a server used by Distributed Denial of Secrets on July 3, 2020, following a request from US authorities, and the seizure became public a few days later. Twitter had already suspended the group’s account under its policy on distributing hacked materials. Neither step put the documents back. The archive stayed available, and a quarter-century of bulletins stayed public.

That is the hard truth of any data leak: response can limit further spread, but it cannot reverse exposure. The decisions that matter most are the ones about what was stored, where and for how long, and they are all made before the breach.

The political consequences arrived in some states. In Maine, BlueLeaks included data from the state’s fusion center, the Maine Information and Analysis Center, at a time when its practices were already under scrutiny. In 2021 the Maine House voted for a bill that would have closed the center. The Senate rejected it, and a separate bill requiring the center to report annually on its activities became law. The leak had turned a security failure into a public argument about what the center should be doing at all, which is the second cost described above.

The broader risk of shared tools serving many agencies recurred. In 2023, exploitation of the MOVEit Transfer file transfer software affected numerous federal, state and local agencies alongside private organizations. File transfer software is the tool organizations use to send large or sensitive files to each other securely. When a flaw in one widely used product was exploited, many unrelated organizations found themselves dealing with the same incident at once, just as the BlueLeaks agencies had. MOVEit also showed that size alone was no protection: the product was widely used and commercially supported.

The access problem did not go away either. In November 2024, the FBI warned companies that criminals were buying and using compromised police and government email accounts to send fraudulent emergency data requests. The mechanism differed from BlueLeaks, but the weakness was the same family. Law enforcement credentials are trusted widely, and too few of them are tied tightly to a verified person in a current role.

The response, over time, followed several of the remedies described here. Shared security assessment programs expanded. FedRAMP, the federal program that assesses cloud services once so that many agencies can rely on the same review, was written into law in December 2022. Texas required its state agencies, from January 2022, to use cloud services certified under its own program, TX-RAMP. The nonprofit StateRAMP program, which announced in February 2025 that it would operate as GovRAMP, offered a shared verification model for state and local governments. Each is the “assess once on behalf of all” approach in institutional form.

The FBI also modernized its CJIS Security Policy to align more closely with NIST controls. Version 5.9.2, released in December 2022, extended multi-factor authentication to access to criminal justice information, with audits enforcing it from October 2024. Version 6.0, at the end of 2024, completed the reorganization around NIST’s control families. NIST, the National Institute of Standards and Technology, publishes widely used catalogs of security controls.

What held up less well was the hope that one leak would change how small shared portals are bought. Assessment programs mostly cover cloud services sold to agencies directly. A modest portal contracted by an association, or renewed under a small-purchase rule, can still fall outside them. The remedies exist; applying them to the long tail of small shared platforms remains a governance choice that each network has to make for itself.

BlueLeaks is best remembered for what it showed about where risk lives. When many organizations share a supplier, the danger is at the level of the shared platform, not any single contract. Someone has to own that level, with the authority and budget to act on it. Otherwise each member assumes the association, the vendor or another member is watching the platform, and none of them is.