A vulnerability disclosure program is a published, low-cost way for outside security researchers to report a flaw in your vehicle, electronic control unit (ECU) or connected product to people who can fix it. For an automotive original equipment manufacturer (OEM) or supplier, the starting kit is small: a security.txt file on your website, a monitored email address, a short policy, and an agreed way to triage what arrives. It is not a bug bounty, and nobody has to be paid.
I once heard the chief information security officer (CISO) of a large OEM refer to security researchers as "extortionists." It was said in jest, but it revealed a common perception: researchers break things and then demand payment under the threat of going public. That picture is overly simple, and it gets in the way of something every product company needs.
At escar USA (Embedded Security in Cars) in 2024, nearly every technical presenter we heard talked about how hard it is to notify vendors about vulnerabilities. The story usually goes the same way: a private report meets a legal threat or silence, the researcher publishes, and the vendor fixes it soon after.
Most researchers simply want to reach the right person and see the issue fixed. This article covers how automotive suppliers and OEMs can give them a way in.
What is a vulnerability disclosure program in automotive?
HackerOne describes responsible disclosure, also called coordinated vulnerability disclosure, as a process where researchers privately alert the affected organization so a flaw can be fixed before anyone exploits it. That's it. In automotive the same process covers vehicles, ECUs, apps, back ends and chargers. Different people own the fix, but the path a report travels is the same: the researcher finds your contact and reports privately, then your team acknowledges, triages, fixes and tells the public.
Good supplier examples are easy to find. Bosch's product security page has a reporting process, a PGP (Pretty Good Privacy) key for encrypted email, and a hall of fame that thanks researchers by name. NVIDIA's vulnerability reporting page offers email to its product security team, encrypted with its published PGP key, or its vulnerability disclosure program on Intigriti.
Why automotive products need one, even after a pentest
Even if your engineering process makes ISO/SAE 21434 (the automotive cybersecurity engineering standard) look like a bedtime story, cybersecurity support for a vehicle can run 20 years or more. Outside researchers will find bugs in that time. A clear, findable reporting path reduces their frustration and gets each vulnerability to you quickly.
The Internet Engineering Task Force put the cost plainly in the opening line of RFC 9116: "When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking." As a result, it says, vulnerabilities may be left unreported.
Penetration testing is still an important part of product security, and it has limits that a disclosure program covers. A pentest is bounded in time by cost and in scope by systems that third parties own, while a real attacker has no scope boundary. Cryptography weakens with age, tools get better, and the best-tested product today will have vulnerabilities found in it later. We wrote about that clock in why an ECU pen test expires at the next release.
A disclosure program is not a bug bounty
A disclosure program does not promise payment for reports; that is what bug bounty programs are for. HackerOne's comparison puts rewards in a disclosure program as "not mandatory or expected." Holding a vulnerability for ransom is also not protected: the US Department of Justice's 2022 charging policy says good-faith security research should not be charged under the Computer Fraud and Abuse Act, and it names discovering vulnerabilities "in order to extort their owners" as outside that protection.
A reward for a major find is still a nice gesture; it is your choice, not the entry fee. The two programs are also different decisions: a form on your site invites reports, while a bounty platform markets your program to researchers and brings in more of them. We cover how to choose in Do You Need a Bug Bounty Program? Start With PSIRT Maturity.
How not to answer a researcher
In 2024 a researcher reported that a traffic-signal controller's web interface could be reached from the internet with no authentication, letting anyone change light timing. As TechCrunch reported, the vendor's general counsel replied with a letter that cited the Computer Fraud and Abuse Act, asked the researcher not to publish details, and said, "We do not have the resources necessary to consider analyses of outdated items."
The researcher published anyway. A simple "Thanks! How can we reproduce this?" would have led somewhere much better.
How to set up a vulnerability disclosure program
Avoid restricting which systems can be tested or how they are accessed; strict rules like that deter reports. A disclosure program is a communication path between outside researchers and your company, and these are the pieces behind it:
- Agree the rules once. Bring legal, PR and security together to decide response times, what an employee may say to a researcher, and when the public hears about a fix. After that, pull in the product owner for each report rather than keeping a standing committee.
- Set up a secure channel. Create a dedicated email address or form and publish a PGP key. Treat attachments with care: a proof-of-concept file is itself something someone sent you from outside.
- Write the policy. Say how to report, what researchers can expect from you, and how and when findings become public.
- Track every report. Put each one in a ticket tracker with an owner, whether that's the tool you already use or VSEC, where a report and the analysis, testing and patch work behind it stay together.
- Know where each component lives. A researcher tells you what they could do to one product. Your engineers then need to find every other product carrying the same component, which is fast only if your asset records are in order.
- Prepare templates. Write acknowledgments, status updates, resolution notes and a thank-you, so every reply is consistent and polite.
- Publish it. Put the program on your website and add a security.txt file in the /.well-known/ folder of your web server. RFC 9116 requires two fields, Contact and Expires, and recommends an expiry less than a year out, so put the renewal on someone's calendar.
- Review it. Revisit the policy, tools and contacts after each report and at least once a year.
Above all, thank every researcher and train the people who will answer them. VSEC Learn has a free starter challenge to begin with.
EU rules will require a reporting path
A disclosure program used to be good manners. For many connected products sold in Europe it becomes a requirement on December 11, 2027. From that date the EU Cyber Resilience Act (CRA) tells manufacturers, in Annex I, Part II, to "put in place and enforce a policy on coordinated vulnerability disclosure" and to provide "a contact address for the reporting of the vulnerabilities."
Since September 11, 2026, manufacturers have already had to report actively exploited vulnerabilities and severe incidents, with an early warning due within 24 hours of becoming aware. Type-approved cars, vans and trucks are excluded, but agricultural machinery, robots and many aftermarket devices are not. We walk through that deadline in CRA reporting starts September 11, 2026.
In October 2026 ENISA, the EU cybersecurity agency, published a technical advisory on security.txt and disclosure policies that recommends the same RFC 9116 file described above. To see how others do it, append "/.well-known/security.txt" to any company's web address.
Start with a contact and a plan
If your automotive products are successful, independent researchers will test them. Build a basic process for talking with the people honest enough to tell you, instead of selling what they found. If you don't have a plan to talk with them, reporters will find a way to contact you.
Most researchers want to share what they found and make your product safer. They'd appreciate a thank-you, they'd enjoy some credit, and for a major find they'd welcome a reward. If you'd like to compare your intake path, policy and triage plan with what we've seen work, tell us where your program stands and we'll talk through what to build first.
Subject expert
Dustin Mills is Director of Product Cybersecurity Engineering & Operations at Block Harbor, where he leads end-to-end engagements with OEMs and suppliers that secure connected vehicles across their lifecycle. He's at his best when working on ambiguous problems that span multiple teams.
%201.svg){kind=logo}
