Five changes are live. One form now writes your vulnerability handling procedure. You can show your readiness on a public page and badge, build an SBOM from a dependency manifest, and pre-fill your ENISA report.
Write your vulnerability handling procedure from one form
Before, you ticked separate checkboxes to say that your procedure was in place. Now you fill in one form. It asks who triages reports, who sends your Article 14 notifications, how you escalate malicious activity, where your reporting address appears, and how long you keep records.
When you save the form, the portal generates a Vulnerability Handling Procedure document that you can download. An authorised officer signs it, and you keep it with your technical documentation. If you already have a policy, you can point to it instead of writing a new one.
Where to find it: Readiness, then Vulnerability Handling Procedure.
Show your readiness to customers and auditors
Procurement teams often ask for proof that you handle vulnerability reports. You can now give them a link instead of a long answer.
- Public verification page. Anyone can open it without an account. It shows your current status and what is on file.
- Badge. Copy a light or a dark version onto your security or product page. It links to your verification page and always shows your current status.
- Attestation letter. A print-ready letter for questionnaires and tender responses. It becomes available when you complete the procedure form.
- Machine-readable status. A JSON file under your portal's
.well-knownpath, for tools that check suppliers automatically.
Publish your reporting channel
Readiness now requires that people outside your company can find your reporting channel. The portal checks your domain for you. If the check passes, the item is marked complete. If your setup blocks the check, you can confirm it by hand. The portal also generates a security.txt file that you can download and publish.
Where to find it: Readiness, then Publish Your Reporting Channel.
Build an SBOM from the files your developers already have
You no longer need a CycloneDX or SPDX file to start. Upload a package.json, requirements.txt, go.mod, Cargo.toml, pom.xml or Gemfile.lock, and the portal reads the components from it. The file type sets the ecosystem.
After each upload, the portal looks up the upstream projects behind your components. It lists them as upstream stakeholders in your obligations, so you know whom to tell when a vulnerability is in their code.
Where to find it: Settings, then SBOM Registry. The SBOM Registry is part of the Reporting plan.
Pre-fill your ENISA report from a submission
When a submission is marked as actively exploited or as a security incident, a new card appears on the submission. It generates a report draft with your company details, the affected components from your SBOM, the CVSS score and the notification timeline. You check it and complete it before you file.
Where to find it: Submissions, then open a submission, then ENISA Notification. Report generation is part of the Reporting plan.
Send alerts to Slack, Microsoft Teams, Discord or your own webhook
Your security team can now get alerts in the tools it already uses. Paste an incoming webhook URL, choose the event, and send a test message. Events include a new submission, an SLA deadline that comes near, and a match in your threat intelligence feed. You need no app install.
Where to find it: Settings, then Integrations. Integrations are part of the Enterprise plan.
Article 14 reporting obligations apply from 11 September 2026. The generated documents help you prepare. They are not a conformity assessment, and this note is not legal advice.