You’ve found something. A memory corruption bug in software running across NHS trusts, or an authentication bypass in a platform used by three government departments. You’ve documented it, written a clean proof-of-concept, and you’re sitting there wondering whether to report it through official channels or just post it on a forum and watch the chaos unfold. If you go the responsible route and report to the NCSC, here’s what actually happens, because the official documentation paints a tidy picture that doesn’t quite match what researchers describe on the other side.
The NCSC’s coordinated vulnerability disclosure framework, explained
The NCSC operates the UK’s central coordinated vulnerability disclosure (CVD) process, sitting underneath GCHQ in Cheltenham. The framework is modelled loosely on international standards, ISO/IEC 29147 for disclosure and 30111 for handling, but adapted for the UK’s specific mix of government systems, critical national infrastructure, and private sector tech. The idea is straightforward: researcher finds bug, researcher reports to NCSC, NCSC contacts the affected vendor or department, everyone agrees a remediation timeline, and a public advisory goes out once a patch exists. Clean. Orderly. In theory.
The NCSC’s vulnerability reporting page gives you an online submission form plus a PGP key for encrypted reports. You can also email them directly. First contact is supposed to trigger an acknowledgement within two working days, and from what I’ve seen, they’re pretty consistent on that front. The triage team reads what you’ve sent, assesses severity using CVSS scoring alongside their own contextual weighting (whether the affected system is CNI, how exploitable it is in the wild, whether there’s active threat actor interest), and then decides who owns the fix.
What the triage process actually looks like
Here’s where it gets interesting. The NCSC doesn’t fix anything itself. It acts as a broker between the researcher and whoever built or operates the vulnerable system. If you’ve found a bug in a vendor’s product, say, a popular enterprise VPN client used across the public sector, the NCSC will contact that vendor and attempt to coordinate a fix timeline. If you’ve found something in a government-owned system, the process routes internally, sometimes through the Cabinet Office or the relevant department’s own technical security team.
The target remediation window is 90 days. That’s not a hard deadline in law, but it’s the standard the NCSC applies before considering whether to advise on limited public disclosure. Some researchers I’ve spoken to say the 90-day window is generally respected, especially for high-severity findings. Others describe situations where a government department has essentially stonewalled the process, citing operational constraints, procurement cycles, or, and this comes up more than you’d expect, the fact that fixing the vulnerable component would require replacing an entire legacy system they don’t have budget to touch.
Where the process breaks down
The biggest friction point isn’t the NCSC itself, most researchers say the team is technically competent and genuinely motivated. The problem is the handoff. Once the NCSC contacts an affected department or vendor, the researcher is largely cut out of the loop. You submit your report, get a case reference, and then wait. The NCSC won’t necessarily tell you what the vendor said, whether they’ve accepted the severity rating, or what the remediation plan looks like. That opacity is deliberate, the NCSC is trying to keep lines of communication open with vendors, and looping a researcher into every exchange would complicate that, but from the researcher’s side it can feel like your report vanished into a void.
This connects to a broader concern about legacy infrastructure. The same class of problems we’ve seen with ransomware groups mapping UK critical national infrastructure, outdated systems, fragmented ownership, no clear party responsible for patching, makes the CVD process genuinely hard to execute. When you can’t identify a single responsible vendor or department for a vulnerability, the broker model struggles. The NCSC has to work out whether it’s talking to a network operator, a software supplier, a managed service provider, or some combination of all three. That takes time, and the 90-day window starts ticking regardless.
There’s also the question of what counts as a government vulnerability versus a vendor vulnerability. Take something like a misconfigured API endpoint leaking data from a government-contracted SaaS platform. The department didn’t write the code; the vendor is based overseas; the data belongs to UK citizens. Who’s responsible? The NCSC will attempt to coordinate, but it has no legal enforcement power over a foreign vendor. It can apply reputational pressure, escalate to international CERT partners, or advise the department to terminate the contract, but it can’t compel a fix on any timeline.
The researcher experience: what people actually say
Bug bounty hunters and independent researchers who’ve gone through the NCSC process have mixed views. The positive feedback clusters around transparency in initial communication, the quality of the triage team’s technical responses, and the fact that the NCSC does issue public advisories when vendors cooperate. The NCSC’s own published advisories are detailed and useful, they’re worth bookmarking if you’re tracking vulnerabilities in UK-deployed software.
The negative feedback centres on a few recurring themes. One is the absence of bug bounty payments. The NCSC doesn’t pay for vulnerability reports. Full stop. If you’ve spent three weeks reverse-engineering a binary to find a critical flaw in a system protecting public sector data, your reward is a thank-you and a credit in an advisory, if you get even that. Several researchers have told me they’ve moved away from reporting UK government findings to the NCSC because the economics don’t work. They’ll report vendor bugs through the vendor’s own programme where there’s money attached, and only escalate to the NCSC when the vendor ignores them.
A second issue is status updates. Once your report is in, you might get silence for weeks. The NCSC says it will update researchers on “significant developments”, but significant is doing a lot of work in that sentence. Researchers who’ve reported high-severity bugs describe waiting 40 or 50 days without meaningful updates, unsure whether the vendor is actively patching or has simply deprioritised the finding. This is similar to frustrations documented around other reporting systems, the kind of opacity that also plagues Action Fraud’s NFIB triage process, where reports go in and nothing tangible seems to come out.
When the NCSC goes public without a patch
The nuclear option in CVD is publishing a vulnerability advisory before a patch exists. The NCSC will do this, they say so explicitly, if the 90-day window passes without meaningful remediation progress, or if they assess that the vulnerability is already being actively exploited in the wild. In practice, this is rare but it does happen. The NCSC’s vulnerability advisories page carries notices where vendors are named alongside unfixed issues, which creates real commercial and reputational pressure.
What researchers want is more transparency about how this decision gets made. The NCSC’s public guidance doesn’t specify exactly what threshold triggers forced disclosure. That ambiguity is probably intentional, rigid rules would let vendors game the timeline, but it leaves researchers uncertain about whether their 90-day clock will actually result in disclosure or quietly extend because the affected system is deemed too sensitive to expose publicly. The tension is sharpest around government-operated systems. Disclosing an unpatched vulnerability in, say, infrastructure touching national security would be handled very differently from disclosing one in a third-party vendor’s product.
What a better process might look like
A few things would genuinely improve the experience without blowing up the framework. Regular status pings to researchers, even automated ones saying “still in remediation, no change”, would cut the anxiety. Some form of recognition or modest financial acknowledgement for critical findings would bring more serious researchers into the official channel rather than pushing them toward private markets or full disclosure. And clearer published criteria for when the NCSC escalates to forced disclosure would make the 90-day window feel like an actual commitment rather than a rough guide.
I’d also argue the NCSC could learn something from how the open disclosure community handles complex multi-party vulnerabilities, the kind of coordination issues that show up when, for instance, a single library flaw affects dozens of systems simultaneously. The leaky public repositories problem across NHS and government GitHub accounts is a good example: multiple responsible parties, unclear ownership, and a finding that’s already semi-public by the time anyone reports it formally. The NCSC’s CVD framework wasn’t really designed for that shape of vulnerability, and it shows.
The framework is worth engaging with. The team is capable and the process, when it works, does result in patches and public advisories that protect real systems. But it’s not the smooth machine the official documentation implies. Go in with realistic expectations, document everything you send, and don’t hold your breath waiting for updates. The bugs you find matter, just don’t expect the process to feel like it knows that.
Frequently Asked Questions
How do I report a vulnerability to the NCSC in the UK?
You can submit a report via the NCSC’s online vulnerability reporting form at ncsc.gov.uk, or email them directly using their published PGP key for encrypted submissions. You should receive an acknowledgement within two working days, along with a case reference number.
Does the NCSC pay bug bounties for vulnerability reports?
No. The NCSC does not pay financial rewards for vulnerability disclosures. Researchers may receive credit in a published advisory, but there is no bounty programme. Many researchers report this as a significant barrier to engaging with the official process.
How long does the NCSC vulnerability disclosure process take?
The NCSC targets a 90-day remediation window from the point of reporting. In practice, timelines vary considerably depending on the vendor’s responsiveness, the complexity of the fix, and whether the affected system is government-operated. Researchers have reported waits well beyond 90 days without resolution.
Leave a Reply