VINCE-NT replaces VINCE: what the switch changes

On 17 September 2026, the US Cybersecurity and Infrastructure Security Agency, CISA (1), brought VINCE-NT into service as the new platform for its coordinated vulnerability disclosure programme, or CVD (2). The date comes from the frequently asked questions published with the platform, which state that the previous platform, VINCE, held that role from 2020 to 17 September 2026. VINCE was sponsored by CISA but hosted by the CERT Coordination Center, or CERT/CC (3), at Carnegie Mellon University’s Software Engineering Institute, or SEI (4). VINCE-NT is sponsored, hosted and managed by CISA alone, at vulnerabilities.cisa.gov.

The switch comes with a rebuilt programme page, published at a new address, and with a public repository, cisagov/VINCE-NT, holding the user documentation, the terms and conditions and the issue tracker. That documentation is live: its pages were edited on 14 and 17 September 2026, and the first issues opened by the team concern account management.

The rebuilt page also adds a section separating coordinated disclosure from a vulnerability disclosure policy, or VDP (5), two arrangements that are regularly confused. Two further agency publications complete the picture: binding operational directive, or BOD (6), 26-04 of 10 June 2026, which replaces and revokes directives 19-02 and 22-01, and the CISA Vulnerability Review of 26 August 2026, covering US federal fiscal years 2024 and 2025, which run from 1 October to 30 September.

Account creation now runs through CISA’s registration portal, backed by Okta. There are two paths: self-service, open to anyone, requiring email verification, a password and at least one multi-factor authentication, or MFA (7), method chosen from an authenticator app, the Okta app or a security key; and a PIV or CAC smart card path reserved for US government employees and partners. The documentation states that the name fields need not hold real names. Sessions are short: an issue opened by the team refers to twenty minutes, and to accounts being disabled after a period of inactivity.

Open cases are handled in the frequently asked questions: active cases move over in the weeks following go-live, with each coordinator announcing the transfer date inside the case; historical data stays readable in VINCE for an unspecified period. According to the agency, the transition affects only those who already used the platform: the CVD team, researchers and suppliers.

Different words, different formats

The change is not only technical. The documentation records a shift in vocabulary and a move towards machine-readable publication formats.

The substantive difference announced concerns vulnerability status: VINCE-NT carries more formal status information than the vendor information field in CERT/CC vulnerability notes, and that information aligns with the CSAF format and with the CVE record format. In other words, the output of the process becomes machine-readable rather than something only a human can parse. For a team that consumes advisories, that is the most structural part of the switch.

The terms and conditions, dated 16 September 2026 and published both in the repository wiki and as a file, are the most instructive piece of the set. They put in writing what used to be a matter of practice.

The marking regime

Coordination runs under the Traffic Light Protocol, or TLP (10). Original information a reporter submits is marked TLP:AMBER. Everything else moving through the platform, messages and documents shared by other parties, is marked TLP:AMBER+STRICT. What CISA publishes is generally marked TLP:CLEAR, with anything left out of the public advisory keeping its original marking. The rule that follows is explicit: publish nothing that comes from the platform, screenshots and messages included, except what you submitted yourself. Failing to respect embargoes and disclosure dates can limit participation in future cases or end the account.

The deadlines

• Five business days: the expected time to acknowledge CISA’s questions, for reporters and suppliers alike.
• Forty-five days: the point from which CISA reserves the right to publish, counted from the first attempt to contact the supplier, with or without a patch, where the supplier does not respond or will not set a reasonable remediation timeframe.
• No stated deadline: CISA may close a case without resolution if the reporter stops answering its questions.

The legal frame

Three clauses are worth reading by a European team. The first ties information submitted by a non-federal entity, where it meets the definition of a cyber threat indicator or defensive measure, to the US information-sharing act of 2015; the text also asks that no personal information unrelated to the threat be included. The second notes that requests made under the Freedom of Information Act, or FOIA (11), go through federal review and adjudication. The third excludes external reports from the vulnerabilities equities process, or VEP (12): CISA is a member of it, but submissions from external reporters are treated as information from security research, intended for rapid disclosure, and are not subject to that adjudication.

Two further clauses have no equivalent on the previous platform. CISA considers the status of reporters, suppliers and other case participants under US screening programmes, including the Consolidated Screening List and the lists kept by the Office of Foreign Assets Control, or OFAC (13), before coordinating; a coordinator then decides on next steps. And regulators may be brought into a case where the product or the affected entity falls under their remit, with CISA notifying the parties beforehand and seeking the supplier’s permission. The text adds a useful point: submitting a report to the platform does not, by itself, satisfy any statutory or regulatory disclosure obligation.

The section added to the programme page addresses a common confusion, in Europe as much as in the United States, where the same word often covers both. The platform’s frequently asked questions go further and name the other arrangement: CISA’s vulnerability disclosure policy service is a separate platform, built for US federal civilian agencies to intake, triage and route reports about their own internet-facing systems.

The distinction is not merely about vocabulary. An organisation publishing a disclosure policy opens an authorised channel to its own exposed assets and commits to what a reporter can expect. An organisation practising coordinated disclosure manages the life of a product flaw through to publication, with an identifier assigned and an advisory written. Both can live in the same entity, but they call on different teams and different commitments.

Submitting does not require an account. The documentation is explicit on a point the programme page does not mention: anyone can submit a report without being authenticated, through the platform’s form. The trade-off is written down too: the agency will still analyse and possibly coordinate the report, but may not be able to communicate with whoever sent it. For a logged-in reporter, the identity and the information supplied are shared with suppliers and, where applicable, with other parties to the case.

A submitted report creates a provisional case in pending status, visible in the reporter’s own view. A coordinator marks it active, and it becomes a tracked case, with messages, file attachments and discussion between the parties. The coordinated disclosure team runs an initial triage, which checks among other things whether the flaw is already known to the supplier or already public, and whether an identifier has already been assigned to it.

Three outcomes come out of that triage. The case is taken on. It is referred, which the page defines as a valid report better handled by another organisation or by the supplier, the reporter being pointed to the right channel. Or it falls outside the programme. Where the flaw appears to meet the identifier programme’s rules, CISA determines whether an identifier should be assigned and which numbering authority, or CNA (14), is responsible. CISA being a CNA itself, it can author the record where that is appropriate.

Two details round out the picture for anyone automating their workflow. Each user can generate an API key from their profile, which opens the way to tracking one’s own cases programmatically. And vulnerabilities in the platform itself are reported either inside the platform, or as a private advisory on the public repository, or by email to the team.

Directive 26-04 binds US federal civilian agencies and no one else. It still deserves a read elsewhere, because it drops a model many organisations still use: a single deadline per severity rating. In its place, four binary variables set the urgency.

The four answers combine into sixteen cases spread across four deadlines: three calendar days, fourteen days, sixty days, or handling at the next system upgrade. The worst combinations, an exposed asset with a catalogued vulnerability that is automatable and grants total control, also require forensic triage to establish whether compromise has already happened. Two fallback rules complete the scheme: unknown exposure is treated as public exposure, and missing enrichment data falls back to sixty days.

The volume effect is what interests a vulnerability management team. According to an initial CISA analysis run at one large civilian agency and reported by a vendor in the field, 1 % of vulnerability instances fell into the three-day tier, and more than 60 % could wait for the next system upgrade. The model is meant to shorten the queue, not lengthen it.

The review presents itself as a baseline drawn before AI-assisted vulnerability discovery becomes widespread. It looks at root causes rather than at flaws one by one, and at the gap between published vulnerabilities and those actually exploited.

The weaknesses that keep coming back

• In 2024, the ten most frequent weaknesses under the CWE (16) taxonomy account for 5.9 % of all published CVEs, two of them injection weaknesses.
• Injection weaknesses of all kinds account for 10.1 % of CVEs in 2024 and 9.2 % in 2025.
• Cross-site scripting, or XSS (17), tops the ranking again in 2025, which the review attributes to persistently poor input validation.
• Memory safety and input validation weaknesses account for 19.7 % of KEV catalogue entries in 2024 and 16.7 % in 2025, far above their share of all CVEs.

The lesson sits in that last gap. Injections dominate publication volume but rarely succeed in a mature environment. Memory safety and input validation dominate the list of what actually gets exploited. A prioritisation built on the volume of CVEs per category therefore produces a different workload from one built on the KEV catalogue.

Exposure and execution

• 520 CVEs were designated for action across critical infrastructure entities over the two years.
• 26 % of the critical infrastructure entities scanned exposed vulnerable network services, around 18 % of them an FTP server.
• CVE-2025-33073, an SMB protocol flaw, was added to the KEV catalogue in October 2025; CVE-2026-24061, granting unauthenticated root access over Telnet, was added in January 2026.
• KEV remediation is getting faster and fewer entities leave an exposure open beyond thirty days, but most organisations still miss the recommended timelines.

The review also presses on the quality of the records themselves: missing CVSS (18) fields, no CWE attribution, incomplete descriptions. Those gaps slow triage and break automation chains, including the ones feeding the prioritisation decision described above. For its own prioritisation, CISA points to the SSVC (19) decision tree, built on five factors: exploitation status, technical impact, automatability, mission prevalence and public well-being impact.

That concern for automation ties the two subjects of this article together. A software capability described by CISA on 14 August 2026, built with the Department of the Treasury, is meant to ingest, validate and deduplicate AI-generated vulnerability reports at scale, ahead of coordination. The document states that it augments the coordination platform rather than replacing it. Moving to statuses aligned with the CSAF and CVE formats makes sense against that prospect of volume.

None of these texts binds a European organisation. Four practical consequences follow all the same.

The first concerns anonymous reporting. It remains possible, the documentation says so, but it has a price: without an account the agency may not be able to reach the author again, and therefore may not be able to ask the questions an identifier assignment needs. With an account, the identity is shared with the suppliers on the case. Choosing between the two is no longer a form detail, it is a trade-off between anonymity and follow-up.

The second concerns the marking regime. A researcher or a team joining a case accepts that their submissions carry TLP:AMBER, that everything else carries TLP:AMBER+STRICT, and that nothing from the platform gets republished, screenshots included. For a team used to feeding its own blog or its own bulletins from its work, that constraint has to be weighed before opening a case, not after.

The third concerns the legal frame. Foreign reports go through a US government platform, with Freedom of Information Act requests subject to federal review, submitted indicators tied to the US information-sharing regime, participants screened against sanctions lists, and the relevant regulators possibly brought in. The most useful clause to retain is the one stating that filing a report with CISA satisfies no European regulatory obligation.

The fourth concerns prioritisation. The four-variable model is portable with nothing owed to the United States, and it has a merit that CVSS-based grids lack: three of the four answers come from an external source, which narrows the qualification work to a single question, the real exposure of the asset. That is also the question most organisations answer badly, for want of a current inventory.

Most of this article rests on the primary documentation CISA published with the platform, read in full. The vulnerability review’s figures are the exception and need confirming against the original file.

If you report flaws

• Check the submission address before creating an account: the two programme pages point to different platforms, and only vulnerabilities.cisa.gov is the new one.
• Decide up front between an anonymous submission and a tracked case: without an account the agency may not be able to reach you, which weighs on identifier assignment.
• Plan for availability: five business days to answer questions, failing which the case can be closed without resolution.
• Read the republication clause before planning any write-up of your own: nothing from the platform may be republished, except what you submitted yourself.
• Prefer the supplier’s own CNA where one exists: agency coordination is built for multi-party cases or unresponsive suppliers.

If you receive reports about your products

• Create the supplier group and identify the authorised people before being party to a case, rather than in the rush of a first one.
• Keep the forty-five-day marker in mind: beyond it, and absent active coordination, CISA reserves publication of the advisory and the record, patch or no patch.
• Prepare to produce vulnerability status in CSAF, the format the platform now aligns with, alongside the record format.

If you manage vulnerabilities

• Take the directive’s four variables and wire them to your own data: exposure from the inventory, catalogue status, automatability and technical impact from public enrichment.
• Treat unknown exposure as public exposure, a fallback rule that holds well outside the federal perimeter.
• Attach a compromise hunt, not just a patch, to the shortest deadline.
• Do not build your workload from the distribution of CVEs per weakness category, given how far it diverges from the KEV catalogue on the families actually exploited.

If you are writing a policy

State in writing which of the two arrangements you are putting in place. A disclosure policy describes an asset scope, an intake channel and what a reporter can expect. A coordinated disclosure programme commits on top of that to triage, identifier assignment and advisory publication, which assumes a mandate, a CNA to work through and the capacity to write. Promising the second while running only the first is the fastest way to lose researchers’ trust.

1. CISA (1): Cybersecurity and Infrastructure Security Agency, the US cybersecurity and infrastructure security agency, part of the Department of Homeland Security.
2. CVD (2): Coordinated Vulnerability Disclosure, the coordination of a vulnerability between a reporter, a supplier and a possible coordinator.
3. CERT/CC (3): CERT Coordination Center, the coordination centre created in 1988, the first of its kind.
4. SEI (4): Software Engineering Institute, the Carnegie Mellon University institute that hosts the CERT/CC.
5. VDP (5): Vulnerability Disclosure Policy, by which an organisation authorises and organises reporting of flaws in its own exposed assets.
6. BOD (6): Binding Operational Directive, compulsory for US federal civilian agencies.
7. MFA (7): Multi-Factor Authentication, requiring several distinct factors.
8. CSAF (8): Common Security Advisory Framework, a standardised machine-readable format for publishing security advisories.
9. CVE (9): Common Vulnerabilities and Exposures, the public identification system for vulnerabilities.
10. TLP (10): Traffic Light Protocol, the marking protocol setting the conditions for onward disclosure. The AMBER+STRICT level restricts sharing to the recipient organisation alone.
11. FOIA (11): Freedom of Information Act, the US law on access to government records.
12. VEP (12): Vulnerabilities Equities Process, the US process arbitrating between disclosing and retaining a vulnerability.
13. OFAC (13): Office of Foreign Assets Control, the US Treasury office responsible for economic and financial sanctions.
14. CNA (14): CVE Numbering Authority, entitled to assign CVE identifiers and publish the matching records.
15. KEV (15): Known Exploited Vulnerabilities, CISA’s catalogue of vulnerabilities with confirmed exploitation.
16. CWE (16): Common Weakness Enumeration, the taxonomy of software weakness types behind vulnerabilities.
17. XSS (17): Cross-Site Scripting, injection of code executed in a user’s browser.
18. CVSS (18): Common Vulnerability Scoring System, the scoring system for the technical severity of a vulnerability.
19. SSVC (19): Stakeholder-Specific Vulnerability Categorization, a prioritisation decision tree accounting for each stakeholder’s context.

1. CISA, The Coordinated Vulnerability Disclosure (CVD) Program, rebuilt programme page, consulted on 18 September 2026. cisa.gov
2. CISA, Coordinated Vulnerability Disclosure Program, earlier page describing VINCE hosted by the SEI. cisa.gov
3. CISA, public repository cisagov/VINCE-NT, documentation and issue tracking. github.com
4. CISA, VINCE-NT Frequently Asked Questions, page edited on 17 September 2026. github.com
5. CISA, VINCE-NT Terms and Conditions, version of 16 September 2026. github.com
6. CISA, VINCE-NT All Users, account creation and management. github.com
7. CISA, VINCE-NT Reporters, submitting and following a report. github.com
8. CISA, the VINCE-NT platform. vulnerabilities.cisa.gov
9. CISA, Vulnerability Disclosure Policy (VDP) Platform, service for federal agencies. cisa.gov
10. CISA, CVE Program Vision, the vision paper referenced by the FAQ, September 2025. cisa.gov
11. CISA, CISA Vulnerability Review, resource page, published 26 August 2026. cisa.gov
12. CISA, CISA Vulnerability Review Fiscal Years 2024 and 2025, 3.43 MB PDF. cisa.gov
13. CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, 10 June 2026. cisa.gov
14. CISA, BOD 26-04: Implementation Guidance, implementation and forensic triage guidance. cisa.gov
15. CISA, press release announcing directive 26-04. cisa.gov
16. CISA and the Department of the Treasury, Gold Eagle: The AI Cybersecurity Clearinghouse, TLP:CLEAR document of 14 August 2026. cisa.gov
17. Industrial Cyber, summary of the vulnerability review, 27 August 2026. industrialcyber.co
18. Software Engineering Institute, announcement of the VINCE launch, June 2020. sei.cmu.edu