Safe harbor for researchers, homework for system owners

The week

On May 19, 2022, the Department of Justice changed how it would treat people who go looking for security flaws. It announced a revised policy for charging cases under the Computer Fraud and Abuse Act, the main federal law against hacking. Deputy Attorney General Lisa Monaco presented the change, which replaced the department’s 2014 charging policy and took effect immediately.

The act makes it a crime to access a computer without authorization or to exceed authorized access. Critics had long argued that those phrases were vague enough to catch people acting in good faith.

Take a resident who notices that changing one number in the web address of a county permit portal brings up someone else’s application, with a home address and phone number. Before 2022, a careful lawyer might have advised her to think twice before telling the county, because federal computer crime law was broad enough that poking at the system could, in theory, be prosecuted.

Under the new policy, federal prosecutors were directed not to charge good-faith security research. The policy defined it as accessing a computer solely to test, investigate or correct a security flaw, in a manner designed to avoid harm, with the information used primarily to promote security. If you were looking for weaknesses in order to get them fixed, and took care not to hurt anyone, federal prosecutors would not treat you as a criminal.

The wording was borrowed rather than invented. The Justice Manual says the definition follows the one used by the Register of Copyrights, who had written a similar exemption for security research into the rules under the Digital Millennium Copyright Act. Researchers already knew that language, which made the new policy easier to read and harder to stretch.

The policy drew a line at pretext. Someone who hunts for holes in devices or services in order to extort their owners might call the activity research, the department said, but it is not research in good faith. A demand for payment in exchange for silence would still look like a crime.

It also added a procedural check. Federal prosecutors weighing a computer crime charge must consult the Computer Crime and Intellectual Property Section, the department’s specialist unit in Washington. An office that wants to charge against that unit’s written recommendation must first inform the Deputy Attorney General’s office. The good-faith exception therefore had an internal guardian rather than a sentence in a manual.

The policy also said that breaches of contractual terms, such as a website’s terms of service, should not on their own be charged. The department’s own examples were mundane: embellishing a dating profile, creating fake accounts, or using a pseudonym on a site that forbids one. Breaking the fine print on a website, by itself, would not be a federal crime.

There was a limit to that limit. If a system owner expressly revoked someone’s access, for example through an unambiguous cease-and-desist letter the person received and understood, later access would count as unauthorized. Researchers who were told clearly to stop could not rely on the policy to keep going.

The change did not come from nowhere. It followed the Supreme Court’s 2021 Van Buren decision, which narrowed the meaning of exceeding authorized access, so that it no longer covered every misuse of information someone was otherwise entitled to see. The case involved a Georgia police sergeant who ran a license plate search for money. The Court held that the phrase covers entering parts of a system one is not entitled to enter, not misusing data from parts one may enter.

The weeks before the announcement had moved the plumbing of disclosure in the same direction. On April 18, the Ninth Circuit, reconsidering the hiQ Labs v. LinkedIn scraping dispute in light of Van Buren, again held that collecting publicly available data was likely not access without authorization. On April 27, the Internet Engineering Task Force published RFC 9116, which standardized security.txt, the small file that tells researchers where to send reports.

Public agencies had also seen the cost of getting this wrong. In October 2021, Missouri’s governor called a newspaper reporter a hacker after the reporter found teachers’ Social Security numbers visible in the page source of a state education department website. The reporter had alerted the department and held the story until the data was removed. In February 2022, the county prosecutor said no charges would be filed.

That episode turned on state law, which shows the limits of what happened on May 19. It was a statement of federal prosecutorial policy, not a change to the statute, and it did not affect state computer crime laws or civil claims. A state prosecutor, or a company filing a lawsuit, was not bound by it. Still, the signal to the security research community was clear: the federal government wanted flaws reported, not hidden.

Van Buren mostly concerned insiders who misuse access they legitimately hold. The DOJ policy dealt with the opposite case: outsiders who probe a system to find weaknesses and report them. The researcher community read it as a reduction in legal risk.

It is easy to misread what the policy changed for a public agency. An agency never had the power to prosecute anyone. What changed was the behavior of the people outside it. A researcher who once weighed the risk of a federal charge before sending an email now had a published federal commitment to point to, and a clearer sense of where the lines were.

That shift did not remove every risk for researchers. State computer crime statutes, civil suits and the reaction of the system owner all still mattered. The Missouri episode a few months earlier had shown that a public official could treat a good-faith report as an attack. Researchers who reported to public bodies still had reason to look for a written promise from the agency itself.

For state and local agencies, the more practical consequence was volume. When researchers feel safer, more of them report, and more reports arrive at organizations that have never received one. A county clerk’s office, a school district or a water utility might suddenly find a message in a general inbox explaining, in technical language, that its website is leaking data. What happens next depends on whether anyone is ready to receive it.

Federal civilian agencies were already set up for this. CISA’s Binding Operational Directive 20-01, issued in 2020, required them to publish vulnerability disclosure policies for internet-facing systems. Most state agencies, counties, cities, courts and school districts had no such requirement and, often, no published process. When a researcher found a flaw in a permit portal or a court records site, the report went to a general inbox or a social media account.

The gap is wider than it looks, because local government is not one kind of organization. A state agency usually has a central IT department and, sometimes, a statewide security office. A county is often a federation of separately elected officials, such as the treasurer, the clerk, the assessor and the sheriff, each with their own systems and budgets. Courts frequently run their own technology under the judicial branch, outside the executive’s control. School districts hold student records under federal privacy rules. Utilities may run industrial control systems that nobody should be testing at all.

Each of these bodies needs the same three capabilities, but the owner of each capability differs. In a county, the IT director may be able to publish a policy for the county website but not for the sheriff’s records system. Mapping who can speak for which system is the first, unglamorous task.

Turning those reports into fixes is an operations problem with three distinct stages. The first is the front door where reports arrive. The second is the route from report to the person who can fix the flaw. The third is closing the loop with the researcher and with leadership.

Six terms behind the policy

A few terms will help leaders follow the rest.

Vulnerability. A weakness in software or a system that someone could exploit to do something they should not be able to do, such as read other people’s records, change data or knock a service offline. Every organization of any size has them. The question is who finds them first.

Security researcher. Someone who looks for vulnerabilities, sometimes professionally, sometimes as a hobby, and sometimes by accident, like the resident who mistyped a web address. Most want the problem fixed. Some hope for recognition or a reward. A few are not acting in good faith at all, which is why reports need judgment.

Vulnerability disclosure policy. A public statement that tells outsiders how to report a flaw, which systems they may test, what they must not do, and how the organization will treat them. It works like a sign on the front of a building. If you notice a broken lock, it says, here is where to tell us, and we will thank you rather than call the police.

BOD 20-01 shows what a full policy contains. It required covered federal agencies to name the systems in scope, the kinds of testing allowed and not allowed, and how to submit a report. It also required a statement that reporters may stay anonymous and a commitment not to pursue legal action over good-faith research that follows the policy. Policies had to say when reporters could expect an acknowledgment.

The directive also listed what a policy may not do. It may not require reporters to hand over personal information, limit testing to vetted or registered parties or to U.S. citizens, or forbid reporters from ever disclosing what they found. Those rules are a reasonable benchmark for any public body, even one the directive does not cover.

CISA and binding operational directives. The Cybersecurity and Infrastructure Security Agency is the federal government’s lead civilian cybersecurity agency. A binding operational directive is an instruction it can issue that federal civilian agencies must follow. BOD 20-01 is the one that made disclosure policies mandatory for those agencies, but it does not reach state or local government.

The directive set a clock. Within 30 days, agencies had to list a security contact for each .gov domain with the registrar. Within 180 days, they had to publish a policy and handling procedures. Scope then had to grow with at least one more system every 90 days, until every internet-accessible system was covered after two years.

Security.txt. A small, standard text file placed on a website that lists where to send security reports. Researchers know to look for it.

The format became a formal internet standard document, RFC 9116, in April 2022, a few weeks before the DOJ announcement. The file lives at a fixed location on a website, under a folder called .well-known, and must list at least a contact address and an expiry date. The expiry date is a useful discipline: a file that is allowed to lapse tells researchers the program may be unattended.

Coordinated disclosure. The practice of reporting a flaw privately to the organization, giving it time to fix the problem, and only then discussing it publicly. It depends on the organization actually responding.

Coordinated disclosure runs on rough timelines. The footnotes to BOD 20-01 recommended acknowledging a report within three business days, completing an initial assessment within seven days, and targeting remediation within 90 days. CISA was careful to call these targets rather than deadlines. Many researchers expect something similar, and a public body that cannot meet them should at least explain why.

The front door

A front door has a published address and published terms. The address can be a dedicated email alias or a web form. List it on a security page and in a standard security.txt file on public websites, where many researchers look first.

The terms say which systems are in scope and which testing methods are off limits. Typical exclusions are accessing other people’s data and denial of service, which means flooding a system with traffic until it stops working. They also say the agency will not pursue legal action against researchers who follow the policy. Agencies should have counsel review that commitment, since state law and the agency’s authority to make it vary. The DOJ policy addresses federal prosecution only, so a local commitment fills a gap the federal one leaves.

Writing the terms

Scope is the hardest drafting decision. An agency can authorize testing only of systems it has the right to authorize. A permitting platform that a vendor hosts for dozens of jurisdictions is not the county’s to open to testing, even though the county’s name appears on the login page. The policy should list such systems as places to report problems, while making clear that active testing of them needs the vendor’s permission.

The same logic applies to systems where testing could cause physical harm. A water utility’s control systems, a 911 dispatch system or a traffic signal network should be listed as out of scope for testing. That exclusion does not mean the agency does not want to hear about problems. It means the agency wants reports from observation, not from experiments on live safety systems.

The data-handling terms matter almost as much. A good policy asks researchers to stop as soon as they have confirmed a flaw, to view no more personal data than they need to prove it, and to delete anything they did retrieve. It also asks them not to share the data with anyone. Those terms protect residents, and they give the agency a clear standard for judging good faith later.

The legal commitment needs care. BOD 20-01 had federal agencies promise not to pursue legal action and to treat compliant research as authorized. That second promise matters, because authorization is exactly what computer crime laws turn on. A county can say it authorizes testing within scope and will not refer good-faith researchers for prosecution. It cannot bind the state attorney general or an elected district attorney, and counsel should say so plainly in the text.

Many agencies ask whether they should pay for reports. A bug bounty, which offers cash for valid findings, can attract more skilled testers. The Department of Defense’s Hack the Pentagon pilot in 2016 showed it could work in government. For most local bodies, gift rules, procurement law and budgets make bounties hard to run. A disclosure policy without payment is the realistic baseline, and the policy should say clearly that no reward is offered.

Staffing the inbox

The front door needs staff behind it. Someone has to read every report, acknowledge it, and judge whether it is credible. Most reports to a public agency are low quality: automated scanner output, missing security headers, or requests for payment. A few are serious. Distinguishing them takes a security analyst, not a general help desk.

To make that concrete: a scanner report might note that a website lacks a particular technical setting that is good practice but rarely dangerous on its own. A serious report might show that changing one number in a link displays another resident’s tax record. Both arrive as emails with technical jargon. Only someone with security training can quickly tell which is which.

For a small agency, that role might be part of a shared service run by the state, a regional consortium or a managed security provider. What matters is that a named person or team owns the inbox and checks it daily.

Federal resources can help. CISA operates a vulnerability disclosure platform for federal agencies, and its published template policy is a reasonable starting point for any public body drafting its own.

Triage follows a short routine. The analyst acknowledges receipt with a standard note and checks whether the system is the agency’s own, a vendor’s or out of scope. The analyst then tries to reproduce the flaw with as little contact with live personal data as possible. Finally, the analyst rates severity on the agency’s existing scale and records the evidence in the ticket.

A second question follows quickly: did anyone else find this first? Server and application logs can show whether the same weakness was used by others before the report arrived. If personal data may have been taken, the matter moves from a vulnerability to a possible breach. State breach notification laws and, for some data, federal rules can then apply, and counsel needs to be involved early.

Reports themselves are sensitive records. A detailed description of an unfixed flaw is a roadmap for an attacker. Many state public records laws exempt security information from disclosure, but the exemptions vary, and agencies should confirm with counsel how such reports will be stored and released. A report sitting in a general inbox that dozens of staff can read is a records problem as well as a security one.

Some messages are not reports at all. A common pattern is the so-called beg bounty: an automated scan result sent with a request for payment. A polite template that thanks the sender, explains that no rewards are offered and invites a specific report if there is one handles most of these. Anything that threatens publication unless the agency pays is not good-faith research and belongs with law enforcement.

The route to the fixer

The weakest link in most disclosure programs is the handoff after a report is validated. Security staff can confirm a flaw. They usually cannot fix it. The fix belongs to an application owner, an infrastructure team or, very often, a vendor.

Public-facing systems in government are heavily vendor-run: payment portals, permitting platforms, court e-filing, library systems, utility billing. A researcher reports to the agency whose name is on the page. If the agency has no contractual way to make the vendor act, it owns the reputational risk without owning the remedy.

Take a county whose online property tax payment page carries the county seal, but the software is run by a vendor that serves dozens of counties. A researcher reports a flaw to the county treasurer’s office. The county’s IT staff confirm it in an afternoon. Then they discover that the contract says nothing about security reports, and the vendor’s support line treats the email as a routine ticket with no deadline. For weeks, the county’s name sits on a known flaw that the county cannot fix.

Contracts and renewals should require vendors to accept forwarded vulnerability reports, acknowledge them within a set time, fix by severity-based deadlines, and tell the agency when a fix is deployed. They should also require the vendor to tell the agency about reports it receives directly that affect the agency’s deployment. That last clause matters because researchers sometimes report to the vendor instead, and an agency that never hears about it cannot judge its own exposure.

What the clause should say

A useful security clause is short and specific. It names a security contact at the vendor who will accept reports forwarded by the agency. It sets an acknowledgment time, defines severity levels, and attaches a fix window to each. It requires the vendor to offer an interim mitigation when a fix will take longer. The vendor must also notify the agency when a fix is deployed and provide enough evidence for the agency to confirm it.

The clause should also flow down. Many vendors host their platforms on a cloud provider or rely on subcontractors for parts of the service. The obligation to accept and act on reports should cover those layers as well, or the vendor will point to a supplier it cannot control.

Agencies buying through cooperative purchasing vehicles, such as state master contracts that local bodies can join, may not be able to add their own terms. That makes the master contract the place to fight for the clause. A state procurement office that writes disclosure obligations into a statewide contract fixes the problem for every county that buys through it.

There is a trade-off. Vendors price obligations into contracts, and tight fix windows for every severity level can raise costs or narrow the field of bidders. A tiered approach, with strict deadlines for critical and high findings and looser ones below, usually gets most of the protection for a fraction of the friction.

Shared platforms, shared flaws

Vendor-run systems create a second problem. When one vendor serves dozens of jurisdictions with the same software, a flaw reported to one county is almost certainly present in the others. The county that receives the report has no obligation, and often no way, to warn its neighbors.

The vendor is the natural party to fix the flaw for everyone, which is another reason the contract should require it to act on forwarded reports. Where the flaw lies in a commercial product, it may also warrant a public identifier through the CVE program, so that every customer can track it. For state, local, tribal and territorial governments, the Multi-State Information Sharing and Analysis Center offers a channel for spreading word of an active threat across jurisdictions.

Inside the agency

Inside the agency, validated reports should enter the same ticketing and severity process as findings from internal scans and penetration tests, with an owner and a due date. A penetration test is an authorized, paid attempt to break into the agency’s own systems; it is essentially the same work an outside researcher does, just commissioned in advance. A separate spreadsheet for outside reports tends to become a list of forgotten items. Severity should follow the agency’s existing scale, adjusted for public exposure and the sensitivity of the data involved.

Severity needs a short worked rule for public data. A flaw that exposes another resident’s name and address may rank higher in a court records system, where some records are sealed for safety reasons, than in a library catalog. A flaw that lets someone change data, such as a permit status or a payment amount, should rank above one that only exposes it. Writing those adjustments down once saves argument every time a report arrives.

The route also needs a deadline owner. Someone, usually the security lead, should track every open external finding against its due date and escalate when a vendor or internal team misses it. Without that person, the route ends at the moment of handoff.

Closing the loop

The last stage has two audiences. The first is the researcher. Researchers who hear nothing tend to follow up, then publish. A short acknowledgment within a few business days, an update when the fix is scheduled, and a note when it is deployed prevent most premature disclosure. Some agencies offer public acknowledgment on a thanks page. Most researchers value a timely, respectful response more than any reward.

The harder conversations come when the agency and the researcher disagree. A researcher may rate a flaw as critical that the agency sees as minor, or may want to publish before a vendor has shipped a fix. The policy can set expectations in advance, such as a request for a reasonable, time-limited delay before publication. BOD 20-01 allowed exactly that kind of request and no more.

When the agency needs more time, saying so early and explaining why usually works better than silence. A researcher who is told that the vendor has committed to a fix by a named date, and who then sees the date met, tends to wait. One who hears nothing for six weeks tends not to.

The second audience is leadership. A disclosure program produces simple, honest metrics: reports received, share validated, time to acknowledge, time to triage and time to remediate, broken out between agency-run and vendor-run systems. That split usually shows where the bottleneck is. If vendor-run systems take far longer to fix, procurement has a contract problem to solve at the next renewal.

Two further measures are useful. The first is aging: how many validated findings are past their due date, and by how long. The second is coverage: what share of the agency’s public-facing systems are named in the policy’s scope. Coverage was how BOD 20-01 measured federal progress, and it works just as well for a county.

The audience for these numbers is often a body that meets in public. A county commission or city council may want to discuss security findings, but detailed discussion of open flaws in an open meeting would help attackers. Many states allow security matters to be discussed in closed session or reported in summary form. Counsel should confirm what the local open-meetings law permits before the first report goes up.

Workforce planning follows from those numbers. An agency that receives a handful of reports a year can absorb them in an existing role. One that runs many public services may need a part-time coordinator, a shared regional service or a contract with a provider. Starting small and measuring is better than either ignoring the inbox or building a large program for a volume that never arrives.

Communications and legal staff belong in the loop as well. Researchers sometimes go public before a fix, and an agency that has agreed in advance how it will respond, and who speaks, avoids a defensive reaction that discourages the next report.

A pre-agreed statement can be brief. It confirms the agency received the report, explains what it has done, and thanks the researcher if the report followed the policy. It avoids language that suggests the researcher is under investigation unless there is a real basis for that. The Missouri episode showed how quickly the opposite approach can become the story.

One report, start to finish

Follow a single report through a well-prepared agency. The stages are easy to describe and surprisingly easy to break.

On a Tuesday evening, a researcher emails the address listed in the security.txt file of a county’s court records site. She explains that searching for a case number in a certain way returns sealed records that should be hidden. She includes steps to reproduce the problem and says she viewed only enough to confirm it.

On Wednesday morning, the analyst who owns the inbox reads the message, sends a short acknowledgment thanking her and promising an update within a week, and tries the steps herself. The flaw is real. Because sealed records are involved, she rates it high severity on the county’s existing scale and opens a ticket in the same system the IT department uses for every other security finding.

The court records site is run by a vendor. The analyst forwards the report through the channel named in the contract, which requires acknowledgment within two business days and a fix for high-severity issues within a set period. She also notifies the court administrator and the county’s counsel, because sealed records may raise legal notification questions that are not hers to decide.

The vendor confirms the problem on Thursday and deploys a fix the following week. The analyst verifies it, closes the ticket and emails the researcher to say the issue is resolved and to thank her. The researcher, satisfied, writes a short, positive note about the experience. At the end of the quarter, the report appears in the numbers the chief information officer presents to the county administrator: one high-severity vendor finding, acknowledged in a day, fixed in under two weeks.

Now run the same report through an agency without the pieces in place. The email goes to a general inbox and stays unread for three weeks. When someone finally reads it, nobody is sure whether it is real. The vendor’s contract has no security clause, so the request joins a queue of routine tickets. The researcher, hearing nothing, follows up twice and then posts about it publicly. The county learns of its sealed-records problem from a local reporter. The flaw was identical; the outcome turned on the policy, the contract and the route to the fixer.

A third version tests the agency’s judgment. Suppose the same researcher, to prove the flaw, downloaded several hundred sealed records rather than viewing one. Her report is still useful and probably still made in good faith, but she has gone beyond what the policy allowed. The analyst’s job is not to decide whether she committed a crime.

The analyst should ask her to delete the records and confirm in writing that she has done so, and log the request. She should also bring in counsel, because the download may itself trigger breach analysis under state law. The policy’s data-handling terms give everyone a fixed standard to apply, which is far better than improvising under pressure.

Free warnings, and the cost of ignoring them

Outside vulnerability reports are free warnings about problems that someone less friendly could find next.

Risk. Every flaw a researcher reports is one that a criminal could also find. An agency that fixes it quickly closes a door before anyone walks through it. An agency that ignores it is, in effect, choosing to learn about the problem later from an attacker or a news story.

Cost. Responding to a report is cheap compared with responding to a breach: notifying affected residents, investigating, restoring systems, and dealing with the public and political fallout. Paid penetration tests cost money; outside reports that arrive through a disclosure program extend that testing at little cost.

Residents and trust. Public agencies hold data people cannot choose to withhold: tax records, court filings, benefits applications, children’s school records. Residents expect that data to be protected, and they judge the agency, not its vendor, when it is not.

Staff. Without a process, reports land on whoever happens to read the inbox. That person may not know what to do, may forward it to the wrong team, or may feel personally responsible for a problem they cannot fix. A clear process protects staff as much as systems.

Oversight and reputation. Auditors, legislators and journalists increasingly ask whether public bodies have disclosure policies. A researcher who publishes a flaw after months of silence makes for a damaging story. One who publishes a thank-you note after a quick fix makes for a good one.

The case against inviting reports

Some officials resist disclosure programs, and their objections deserve a fair hearing. The first is that a published policy invites probing. That is partly true: some people will test systems they would otherwise have ignored. Attackers already probe every public system, however, and a policy changes the behavior of the people most likely to tell the agency what they found.

The second objection is workload. A small team can be swamped by automated scan results and payment requests. Templates, a clear scope and a shared triage service answer most of that concern, and the metrics will show whether volume justifies more staff.

The third is legal. A promise not to pursue researchers can seem to tie the agency’s hands. The promise covers only research that follows the policy, and it does not bind other prosecutors. Extortion, data theft and disruptive testing remain outside it.

The fourth is embarrassment. A flaw that becomes public can hurt the agency’s reputation. Coordinated disclosure exists to reduce that risk by giving the agency time to fix the problem first. The embarrassment that does lasting damage is the flaw that sat unfixed after a report, not the one fixed quickly.

The argument is weakest for the smallest bodies. Take a township whose only public system is a vendor-hosted payment page. It may get more from a vendor with a good disclosure program, and a contract that routes reports, than from building its own. Even then, someone at the township needs to know where a report should go.

A city program that works, and how others break

Take a well-run program at a mid-sized city. Its website has a security page and a security.txt file pointing to a dedicated address. The policy, reviewed by the city attorney, lists the systems in scope, rules out disruptive testing and promises not to pursue good-faith researchers. A small team in the IT department, backed by the state’s shared security service, reads the inbox each morning and acknowledges every credible report within two business days. Validated flaws go into the same ticket system as internal findings. Vendor contracts require acknowledgment and fixes within set times. Each quarter, the chief information officer reports the numbers to the city manager, with vendor-run systems shown separately.

Programs elsewhere tend to break in predictable ways:

• No front door at all. Reports arrive through a general contact form or social media, and nobody knows they are security reports.
• An inbox nobody owns. A dedicated address is set up, then left unread when the person who created it changes roles.
• Treating the reporter as the threat. A defensive or legalistic first response, or a referral to law enforcement for good-faith research, discourages future reports and often prompts public disclosure.
• Contracts with no teeth. Vendor agreements that say nothing about security reports leave the agency unable to compel a fix.
• A separate list. Outside reports tracked in their own spreadsheet, outside the normal remediation process, are easy to forget.
• Overbuilding. Launching an expensive program before knowing how many reports will arrive, when a modest, measured start would do.

How the setting changes the program

The same building blocks look different in each kind of public body.

State agencies. A central IT agency can publish one policy covering many departments, run a shared inbox and write disclosure clauses into statewide contracts. The risk is that departments with their own systems assume the central program covers them when it does not.

Counties. Separately elected officials often control their own systems. A countywide policy needs their agreement, and the route to the fixer may run through several offices. Starting with the county website and the systems IT directly manages is reasonable, with others added as their owners agree.

Courts. Judicial branch systems hold sealed and confidential records and often answer to a state court administrator rather than the county. Court IT may need its own policy, or explicit inclusion in a state judicial branch program.

School districts. Districts rely heavily on education technology vendors that hold student records. Federal student privacy rules shape how exposures must be handled. Contracts with those vendors are where most of the work lies.

Utilities. Billing portals belong in scope. Operational technology, the systems that run pumps, valves and treatment, should be excluded from testing and listed as a place to report observations only. The utility’s operations staff need to be part of triage alongside IT.

What a public body’s front door needs

• If someone found a security flaw in one of our public websites today, where would they report it, and how would they know?
• Who reads security reports, how often, and who covers when that person is away?
• Which of our public-facing systems are run by vendors, and what do their contracts require when we forward a security report?
• Are validated outside reports tracked in the same system, with the same deadlines, as findings from our own testing?
• If a researcher went public before we fixed something, who would speak for us, and what would they say?

These are management questions, not technical ones. The answers show whether an agency is ready to receive the help that outside researchers, encouraged by the federal policy, are increasingly willing to offer.

A first ninety days

An agency starting from nothing can stand up a credible front door in about a quarter. In the first two weeks, it creates a dedicated address, names an owner and a backup, and publishes a security.txt file pointing to it. In the next month, it drafts a policy from CISA’s template, has counsel review the legal commitment and the scope, and lists its vendor-run systems.

In the final month, it writes the triage templates, agrees severity adjustments for public data, connects the inbox to the ticketing system and briefs communications staff. It also adds the vendor clause to the renewal calendar. Measurement starts on day one, so that the first quarterly report shows a baseline rather than an estimate.

With hindsight

The policy has held. The computer fraud section of the Justice Manual still carries the May 2022 language as far as we can tell, and we are not aware of it being withdrawn. For researchers, that durability matters as much as the original announcement, because a safe harbor that might vanish next year does little to change behavior.

What has not changed is the statute. As far as we are aware, Congress has not rewritten the act’s core language on authorization since 2022. Researchers’ protection still rests on prosecutorial discretion and on the Supreme Court’s narrower reading in Van Buren. Civil suits under the act remain possible, and state computer crime laws still vary widely.

The federal agencies covered by BOD 20-01 reached the directive’s final milestone in September 2022, two years after it was issued. From then on, every internet-accessible system those agencies ran had to be in scope of their disclosure policies. CISA’s shared disclosure platform, launched in July 2021 with contractors doing first-pass triage, gave smaller federal agencies a front door they did not have to build alone.

The expectation also began to reach contractors. In May 2023, NIST published its recommendations for federal vulnerability disclosure guidelines, SP 800-216, under the IoT Cybersecurity Improvement Act of 2020. The guidance aligns with the international standards for disclosure and handling and extends the federal model toward contractors that supply information systems to agencies.

Around it, vulnerability disclosure has moved from courtesy to expectation. CISA launched its secure-by-design program with international partners in April 2023. At the RSA Conference in May 2024, it added a voluntary pledge for software makers. One of the pledge’s goals was to publish a disclosure policy that authorizes good-faith testing and forgoes legal action against researchers who follow it.

Signatures grew quickly, and that pushed vendors serving government to accept outside reports. The pledge was voluntary and carried no enforcement. For agencies that rely on those vendors, it still helped close part of the gap described above, where the agency’s name is on a system it cannot fix directly.

Europe went further. The European Union’s Cyber Resilience Act, which entered into force in December 2024, requires manufacturers of products with digital elements to handle vulnerabilities through coordinated disclosure. Its reporting obligations began on September 11, 2026, a month before this article. Manufacturers must now send an early warning about an actively exploited vulnerability within 24 hours, through a single platform run by ENISA, the EU’s cybersecurity agency. Most of the act’s other obligations apply from December 2027.

Products with digital elements covers a wide range of hardware and software, and many of the vendors that serve American public agencies also sell in Europe. Practices built to meet that law are likely to show up in the products agencies buy. The United Kingdom took a narrower step in April 2024, when its product security regime began requiring makers of consumer connectable products to publish how to report security issues.

The ecosystem also showed its fragility. In April 2025, the contract under which MITRE runs the CVE program, the public system that gives each known flaw an identifier, came within a day of lapsing. CISA extended it at the last moment for eleven months. Disclosure depends on shared infrastructure that most agencies never think about until it wobbles.

Closer to home, a number of states, often through their central IT agencies, have published disclosure policies for state systems, though coverage at the county and city level remains uneven. The federal directive that covered federal agencies in 2020 still has no general equivalent for the thousands of local bodies that run permit portals, court sites and utility billing.

The weak point has not changed. Agencies that wired outside reports into their normal remediation process, and wrote vendor obligations into contracts, now treat researchers as extra testing capacity. Those that did not still learn about their flaws from public posts.

Agencies do not need to wait for a mandate. A published front door, a named owner, a route to the fixer and a habit of closing the loop are within reach of almost any public body. The next vendor contract renewal is a natural place to begin.