Annex I Part II (6) Vulnerability information sharing and contact address

What the CRA requires for vulnerability contact addresses and information sharing

Annex I Part II point (6) asks a manufacturer to make it easy for outside parties to share information about potential vulnerabilities in the product and in its third-party components, and it names a contact address for vulnerability reports as the core measure. If you are preparing a product for the EU market, the practical question is simple: when a security researcher, a customer or a component maintainer finds a problem, does a monitored route exist that reaches someone who can triage it, and is that route documented in a place the reporter can find? The requirement is about the existence and reachability of that channel, not about how you respond to what arrives through it. That response work sits with the disclosure policy in point (5) and the remediation duties in point (2). The two obligations are easy to confuse. Point (5) covers the coordinated vulnerability disclosure policy itself: its content, how users find it, and how it stays in force for every supported version. Point (6) is narrower and more operational: a published contact address and the measures that let information flow in. Article 13(17) adds a single point of contact that users can easily identify, that lets them choose their preferred means of communication and that is not limited to automated tools, so a web form alone does not satisfy it. Annex VII point 2(b) then requires your technical documentation to contain evidence that the contact address has been provided, which means you should keep a dated record of where it is published, not just the address itself.

In practice the requirement fails in predictable ways. A generic inbox such as security@ may have no owner, no escalation path and no one checking it during holidays. Third-party components are harder still: Article 13(6) requires you to report vulnerabilities you find in integrated components to the party maintaining them, and to share fixes where you developed one, but many teams cannot name the maintainer of every library they ship. Before you publish a contact address, confirm who reads it, who can reach the engineering owner for each product line, which components have a known upstream security contact, and how a report about a component you did not write gets forwarded and tracked. Write those answers down, because the documentation evidence an assessor will ask for is the same record.

Which products, teams and third-party components fall in scope for the reporting contact

The contact address and single point of contact under Annex I Part II (6) apply to every product with digital elements placed on the EU market, so the real scoping work is deciding which product, team and component boundaries the reporting channel must cover. The cards below separate those decisions so each one has a named owner and a documented answer.

In-scope products with digital elements

Any product with digital elements placed on the EU market falls in scope, including hardware with embedded software and standalone software. Start with a product inventory that lists each shipped version, its intended use and whether it is commercially supplied. Record the boundary of each product so the reporting address covers the whole product, not only the headline application. Confirm the treatment of SaaS and cloud-hosted elements against the Commission guidance and your own classification, since the answer changes what sits inside the product boundary.

Security team as the intake owner

The product security or PSIRT function should own the vulnerability reporting address and triage incoming reports. Its job is to confirm receipt, assess severity against the product's risk assessment and route the report to engineering. Name a deputy and a documented hand-off so reports are not left in a shared mailbox. Ask who is accountable for acknowledging reports and who can authorize external communication about a finding.

Support and customer teams as the user channel

Article 13(17) requires a single point of contact that users can easily identify and that is not limited to automated tools. Support staff are usually the first people users speak to, so they need a script, an escalation path and access to the same tracking record as the security team. Confirm that users can choose their preferred means of communication and that a human can respond to each channel.

Legal and product teams on disclosure

Legal reviews the wording of the disclosure policy, the contact terms and any statements to customers, while product owners decide release timing and affected-version wording. Agree in advance who signs off on a public statement and how quickly. Mismatched sign-off is a common reason disclosure slips, so write the approval chain down before a report arrives.

Integrated third-party and open-source components

Vulnerabilities often originate in libraries, firmware or cloud services the manufacturer did not write. Point (6) covers third-party components, so the reporting process must accept findings about them and route them to the maintainer. Where you develop a fix, Article 13(6) requires you to report it to the person or entity maintaining the component and share the code or documentation, where appropriate in a machine-readable format. Confirm which components are in your SBOM and who is the upstream contact for each.

Support period and scope checks

The contact address must remain in place for the whole support period, so scoping decisions affect how long the channel must run. Confirm the support period for each product, how versions are retired and which older releases still receive reports. Cloud and SaaS elements may require different handling, so check the scope decision with the Commission guidance and your own product classification before you publish the address.

How an assessor tests the vulnerability contact address

This table sets out each test step an assessor is likely to run for Annex I Part II (6), the evidence requested for it and the findings that usually fail. Read it as a checklist to run against your live product before a conformity assessment, since the assessor will compare what you document with what users actually encounter.

Test element	What the assessor checks	Evidence requested	Common findings
Published contact address	A contact address for reporting vulnerabilities is visible to outsiders and is reachable without logging in or signing a contract.	Screenshots or URLs of the published address, with the date captured and the location in the product, website or documentation.	Address buried in a legal notice, or only listed in an internal wiki that outside reporters cannot reach.
Monitoring and delivery	Messages sent to the address reach a mailbox or queue that someone watches, and delivery does not fail silently.	Mail server or ticketing configuration, a test message sent during the assessment, and a record of recent reports received and triaged.	Address bounces, forwards to an unmonitored list, or accepts mail that nobody reads.
Named owner and routing	A named role or team owns the address, and reports are routed to people who can act on them.	Written ownership assignment, escalation path to the product security team, and a RACI or on-call record.	No named owner, or an owner who has left the organization while the address still forwards to them.
Single point of contact for users	Article 13(17) requires a single point of contact that users can easily identify and that offers choice of channel, not only automated tools.	Contact page or product notice showing the point of contact, the channels offered, and proof that a person answers through at least one of them.	Only a chatbot or web form is offered, or the contact is hidden behind several menus.
Human follow-up	Reports submitted through forms, portals or automated tools receive a human response within the timelines the organization has set.	Sample of reports with timestamps for acknowledgement and triage, plus the internal procedure that defines those timelines.	Form submissions generate an automatic reply and then no human follow-up is recorded.
Annex VII 2(b) technical documentation	The technical documentation contains evidence that the contact address has been provided, as Annex VII point 2(b) requires.	Technical documentation section naming the address, with a dated copy of the publication and a link to the version of the product it covers.	Documentation omits the address or describes a different address from the one the product publishes.
Consistency with the live product	The address, channels and owner in the documentation match what the product, website and user materials show today.	Side-by-side comparison of documentation, product notices and public pages, signed off by the product owner.	Documentation was written for an earlier release and names an address or process that has since changed.
Third-party component reports	Vulnerabilities found in integrated components can reach the manufacturer, and the manufacturer can pass them to the component maintainer under Article 13(6).	Process describing how inbound reports about components are triaged and forwarded, with examples of forwarding records.	Component reports arrive at the contact address but nobody checks the component's upstream maintainer.

How to set up a reporting address and information sharing process

This sequence turns the Annex I Part II (6) duty into working intake: a named owner, a published reporting address and single point of contact, a triage queue, a path for third-party component issues, and a documented record that an assessor can inspect.

Assign a named owner for vulnerability reports
Name one accountable person or role, usually the product security lead or PSIRT coordinator, and a deputy. This owner decides who triages reports, who approves outbound disclosure and who answers the regulator when asked. Write the assignment into the product security governance record with the scope covering every version still in its support period. Done means the owner has accepted the role in writing and the deputy can act without them.
Create a dedicated vulnerability reporting address
Set up a monitored mailbox or web form used only for vulnerability reports, separate from general support. Restrict who can read it, log every message and confirm that automatic replies point reporters to the disclosure policy. Test delivery from an outside account and record the test result. Done means the address works from outside the company, is monitored by named staff and appears in the technical documentation as the contact address for reporting vulnerabilities.
Publish the address and single point of contact
Place the reporting address where users and security researchers look: the product's security page, the documentation, the support portal, the product's own about or settings screens, and the coordinated disclosure policy. Name a single point of contact for users that is more than an automated channel, and state the means of communication users can choose. Done means a dated capture of each location is stored with the evidence file, and the links resolve.
Set up intake and triage in a findings system
Route each report into a ticketing or vulnerability management system so it gets an identifier, a severity estimate, an owner and a status history. Open-source options include DefectDojo, which imports findings from many scanner report formats and deduplicates them, and Greenbone for internal scan results. Define triage states such as received, confirmed, not affected and fixed, and who moves a report between them. Done means a test report flows from the mailbox to a tracked record with an audit trail.
Define the path for third-party component vulnerabilities
Maintain a list of the third-party and open-source components in the product, using the SBOM from the identification step, and record who maintains each one and where its vulnerability contact is. When a confirmed issue sits in a component, forward it to the maintainer, track the forwarding in the same record and, where you have developed a fix, plan to share the code or documentation as Article 13(6) requires. Confirm the maintainer's reporting channel before an incident, not during one. Done means each component has a named upstream contact and a forwarding template exists.
Record how information flows to users and internal teams
Document how confirmed vulnerabilities reach the users who need them, which teams act on them, and how the single point of contact is kept informed. Link this to the disclosure and advisory steps so that users receive instructions without delay once a fix exists. Consider whether any threat intelligence sharing will use tools such as MISP or OpenCTI, and note whether it is internal or external. Done means a written flow chart or procedure names the roles, channels and handoffs.
Record the setup in technical documentation
Add the reporting address, the single point of contact, the triage procedure, the component forwarding path and the owner to the technical documentation that Annex VII requires. Store dated screenshots, mailbox test results, the triage system configuration and the signed owner assignment alongside it. Ask your conformity assessment body or notified body which evidence format they expect. Done means an assessor could trace each element of the reporting process to a stored artifact and a named person.

How reports from outside parties reach the right team

A report from an outside party about a vulnerability in your product should reach a named owner through a path you have designed in advance, not through whichever inbox received it. The flow starts at the contact address and the single point of contact described under Annex I Part II (6), then moves through triage, deduplication and, where the flaw sits in someone else's code, forwarding to the party that maintains it. Each step needs an owner, a record and a timestamp, because the same intake will later feed the Article 14 reporting decision for actively exploited vulnerabilities. Before go-live, confirm who is on the intake rota, who has authority to declare a finding valid, and how reports arriving through a human channel are logged alongside those from automated scanners.

Triage separates three things: whether the report describes a real defect, whether it affects a version you still support, and whether the component involved is your own code or an integrated third-party component. Deduplication matters because scanners and researchers often report the same flaw repeatedly. In a self-hosted setup, DefectDojo can ingest findings from many tool formats and deduplicates them using per-tool hashcode fields, which lets the intake team merge external reports with internal scan output into one register. Confirm that your chosen tool's deduplication keys match the way your scanners fingerprint findings, or duplicates will multiply rather than collapse.

Article 13(6) covers flaws in integrated components. When a report concerns a component you ship but do not maintain, you must report the vulnerability to the person or entity that maintains it. If you have developed a fix yourself, you must share the code or documentation, where appropriate in a machine-readable format. The practical decision is whether your fix is a patch that belongs upstream or a local workaround that should stay private, and that decision should be recorded with the reasoning. Keep a register of every upstream forward, the date sent and any acknowledgment received, so you can show an assessor that the duty was met for each affected component. The exact wording and scope of this duty should be checked against the regulation text and the current Commission guidance before you rely on it.

Evidence that passes an assessment for the reporting contact

Annex I Part II (6) is tested through a small set of records that show the contact address exists, is findable, and is actually worked. The cards below cover each artifact an assessor is likely to request and how to keep it current between formal reviews.

Published contact page and version history

Keep a public page that states the vulnerability reporting address, links to the coordinated disclosure policy, and names the single point of contact for users. Store every revision with a date and the person who approved it, so you can show what the address was at any point in the support period. Check the page after each release and confirm the address still resolves to a monitored inbox. Ask your counsel whether the page language matches what the technical documentation claims.

Intake mailbox or form configuration

Export the settings for the reporting mailbox or web form: who can read it, forwarding rules, auto-responders, spam filtering and retention. Assessors check that reports are not silently dropped by a filter or sent to a departed employee's account. Record the configuration in version control or a change log, and review access rights whenever staff change roles. A dedicated alias is easier to evidence than a personal address.

Single point of contact description

Write a short description of the user-facing contact channel that explains how users reach a person, which means of communication they may choose, and that the channel is not limited to automated tools. Article 13(17) expects users to identify this point easily, so the description should appear where users look for support. Keep a copy of each version with its publication date, and confirm that phone, email or ticket options still work after any support tooling change.

Triage records showing report handling

Maintain a log for each report with receipt date, acknowledgement sent, severity assessment, owner, decision and closure reason. The log shows the contact address is operational, not decorative. Redact reporter identities where needed, but keep timestamps and decisions intact. Sample several entries before an audit to confirm they are complete and consistent with your disclosure policy timelines.

Third-party maintainer notification log

Where a report concerns a component you did not write, record each notification sent to the person or entity maintaining that component, with date, channel and any response. Article 13(6) requires this step for integrated components, and assessors will ask how you know the upstream maintainer was told. Keep the record linked to the triage entry so the chain from report to upstream notice is traceable.

Technical documentation reference to the address

Annex VII point 2(b) requires the technical documentation to contain evidence that a reporting contact address has been provided. Include the address, the page where it is published, and the date it was last verified in the documentation index. Assessors compare this reference against the live page, so any mismatch is an easy finding. Assign an owner to re-verify the reference at each release.

What meeting Annex I Part II (6) costs in money and effort

This table breaks down the cost components of running a vulnerability contact address and single point of contact, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to shape a written scope and to ask a partner or vendor for a quote that separates tooling, staff time and review. No fees or durations are given because none are supplied for this requirement.

Cost component	Who is paid or who bears the cost	One-time or recurring	What drives it
Intake tooling and licenses	Software vendor or open-source operator; DeployOpen for setup if scoped	Setup one-time, hosting and any subscriptions recurring	Report volume, number of product lines, and whether a commercial tracker is chosen; self-hosted open source can remove license spend
Triage and engineering time	Internal PSIRT or security engineers, or a contracted team	Recurring	Number of reports, severity mix, and how many third-party components must be checked and routed to their maintainers
Legal review of the published address and policy	Internal legal or outside counsel	One-time per revision, plus periodic review	Wording of disclosure terms, number of markets served, and how often the policy changes
Single point of contact operation	Internal support or customer success staff	Recurring	User base, preferred channels offered beyond automated tools, and expected response coverage
Documentation upkeep for technical documentation	Product security or compliance team, with engineering input	Recurring with each release	Number of product versions in the support period and how often the contact evidence is re-verified
Third-party component coordination	Internal engineering with upstream maintainers	Recurring	Count of integrated components, how many maintainers have public reporting routes, and whether fixes must be shared
External review and penetration testing	Independent testers or consultants, engaged on a written scope	Periodic	Product complexity, change frequency and how much of the intake process is tested
Assessor sampling and evidence requests	Internal compliance staff; the independent assessment body issues any conclusions	Periodic, around each assessment	Number of reports received, how well records are kept, and how quickly evidence can be produced

Who owns the contact address, who prepares evidence and who assesses it

The manufacturer owns this requirement. Under Annex I Part II point (6), the manufacturer must take measures to facilitate sharing of information about potential vulnerabilities in its product and in third-party components, including a contact address for reporting. Article 13(17) adds a single point of contact that users can easily identify, that lets them pick their preferred channel and that is not limited to automated tools. Accountability for both sits with the manufacturer's leadership, not with any vendor or consultant.

Decision ownership: Choose the reporting address, the intake channels and the staffing that answers them, and approve the published wording.
Ongoing operation: Staff the mailbox or queue, acknowledge reports and keep the contact details current on the product, packaging, website and documentation.
Third-party components: Route reports about integrated components to the maintainer and track the handoff, as Article 13(6) requires.
Technical documentation: Keep the evidence that a contact address has been provided, which Annex VII point 2(b) requires in the technical file.
Signed responsibility: Declare conformity and keep the file for the period the regulation requires.

Before relying on the setup, confirm the current wording of Article 13(17) and Annex VII with your legal counsel using the Regulation text on EUR-Lex.

Where manufacturers fall short on vulnerability contact addresses

Most manufacturers can point to a security email address, but an assessor will ask who reads it, how it connects to the technical file, and what happened to the last report. The gaps below cluster around ownership, routing and records, and each one has a concrete fix that can be checked before a market surveillance authority asks.

An address with no named owner

A generic mailbox such as security@ may exist, but nobody is accountable for reading it, answering it or escalating it. Annex I Part II (6) expects the address to function, so check that a named role owns it, that a backup covers absences, and that the people behind it know the regulation's reporting timelines under Article 14. Write the owner's role into the vulnerability handling procedure.

A point of contact limited to a chatbot

Article 13(17) requires a single point of contact that users can easily identify and that lets them choose their means of communication, and that is not limited to automated tools. A web form or chatbot that is the only route fails this test. Confirm that a person can be reached by email or phone, and that automated intake is an addition rather than the sole channel.

No link to technical documentation

Annex VII point 2(b) requires the technical documentation to contain evidence that a vulnerability contact address has been provided. Teams often publish the address on a website but never record where it appears in the file. Keep a dated screenshot or archived copy of the published address, reference its URL and version in the technical documentation, and review the link at each release.

Third-party components with no maintainer route

Article 13(6) requires manufacturers to report vulnerabilities in integrated components to the person or entity maintaining them, and to share a fix where one exists. Many products bundle libraries whose maintainers have no route for the manufacturer to use. Inventory each component from the SBOM, record its maintainer and reporting channel, and flag components where no channel exists for a decision.

No record of triage

Receiving a report is not enough. Without a log showing receipt time, severity assessment, owner, decision and response to the reporter, a manufacturer cannot show that the address works. Use a ticketing system or a findings tool such as DefectDojo, which imports findings from more than 500 security tool report formats and deduplicates them, so each report has a traceable record from intake to closure.

Intake not connected to the disclosure policy

The contact address, the coordinated vulnerability disclosure policy and the public description of fixed vulnerabilities should describe the same process. When the policy promises an acknowledgment window or a reporter contact, but the mailbox has no one assigned, the mismatch is visible to reporters and assessors alike. Compare the three documents against the actual intake workflow each quarter.

Questions buyers ask about the CRA reporting contact

Is a generic security inbox enough to meet the CRA vulnerability contact requirement?

A generic inbox can serve as the contact address for vulnerability reports, but it is rarely enough on its own. The requirement under Annex I Part II point (6) is to facilitate information sharing and provide a contact address for reporting vulnerabilities, and Article 13(17) separately requires a single point of contact that users can easily identify and that is not limited to automated tools. A monitored mailbox with named owners, a documented triage path and a way for users to choose their preferred channel covers more of that intent. The evidence you will need to show an assessor includes the published address, the process behind it and records of how reports were handled.

How much effort does setting up a CRA reporting contact take, and what drives it?

The effort depends mostly on how many products you place on the market, how many channels you offer and how much intake already exists. A single product with one existing security mailbox may need a documented triage procedure, a published page and a retention rule for reports. A portfolio with several product lines, third-party components and multiple user groups needs routing rules, ownership per product and a way to link reports to the technical documentation. Ask any provider to break its quote into discovery, intake design, publication, testing with a sample report and handover, and to state which items are one-time and which recur.

Can open-source tools handle vulnerability report intake?

Open-source tools can support intake and triage, but they do not write the policy or decide who answers. DefectDojo, for example, imports findings from more than 500 security tool report formats and deduplicates them using per-tool hashcode fields, which helps when reports arrive from scanners and internal testing. MISP and OpenCTI are better suited to threat intelligence sharing than to user-facing report intake, so confirm their fit before relying on them for that role. Whatever tools you choose, confirm the capabilities you need in the current release and document how each report moves from receipt to closure.

What does the internal team need to provide for the reporting contact to work?

The internal team must own the decisions that a partner cannot make for you. That includes naming who reads reports, who decides severity, who approves public statements and who contacts downstream users. Engineering must be able to confirm which components are in each product and who maintains them, because Article 13(6) requires reporting vulnerabilities in integrated components to their maintainers. Legal or compliance should review wording so that the published contact and policy match your obligations. Plan for the reviewers' time as a recurring commitment, not a one-off task.

Who is responsible for the contact address, the organization or the implementation partner?

The organization owns the contact address, the policy and every decision made on a report. An implementation partner such as DeployOpen can plan, configure and document a self-hosted intake and triage setup inside your own infrastructure, and can help prepare the evidence that the technical documentation needs. Only an independent auditor or certification body issues reports or certificates. Write this split into the statement of work so that each deliverable has a named owner.

When should we bring in an implementation partner for the reporting contact?

Bring in a partner when the intake work is larger than your team can staff alongside product delivery, or when you need a self-hosted system built and documented in your own environment. Typical triggers include a growing product portfolio, no existing triage tooling, or an approaching reporting date that leaves little room for design and testing. Most engagements are fixed-scope, so agree the scope, deliverables and timeline in writing before work starts. Ask for a written scope that lists the systems, the documentation and the handover, and confirm what support is included after go-live.

What should we check before publishing the contact address?

Check that the address reaches a monitored queue, that someone is accountable for it during business hours and that the channel does not depend solely on an automated responder. Confirm the page where users find the contact is linked from the product and the support site, and that it matches the coordinated vulnerability disclosure policy. Send a test report, record how it was triaged and keep that record as evidence. Confirm the current Article 13 and Annex VII wording with the EUR-Lex text before finalizing your documentation.

Self-hosted open-source tools that help record and triage reports

Reports about a product often arrive from several places at once: scanner output, penetration test results, researcher emails and findings from component maintainers. DefectDojo is an open-source application that can import these results into one place, track them to resolution and remove duplicates. According to its documentation, it imports and reimports findings from more than 500 security tool report formats through the UI or API, including in the open source edition, and it has a generic findings import for everything else.

Format coverage: Confirm that the scanners and report types your teams already use are supported in the version you deploy, since the list changes over time.
Deduplication: Findings are matched using per-tool hashcode fields, so a repeat report of the same issue can be linked rather than counted twice. Confirm how well the matching works for your scanners before relying on it for counts.
Generic import: Researcher reports and manually written findings can be loaded through the generic format, which keeps one record per report.
Self-hosting: The application runs inside your own infrastructure, so reports containing unpatched vulnerability details stay under your access controls.
Licence: DefectDojo is released under the BSD-3-Clause licence. Review its terms with your legal team if you plan to modify or redistribute it.

Before you rely on the tool, ask DeployOpen or your own engineers to confirm the importers, the deduplication settings and the retention rules against your actual scanner outputs.

How DeployOpen prepares a reporting contact and its evidence

DeployOpen starts this work with a written scope that names the products, the vulnerability reporting address, the people who will staff the intake queue and the evidence the internal team needs to keep. The scope decides what is built and what is left to the client, so it should be agreed before any system is installed. A useful first decision is whether the reporting address is a shared mailbox, a web form backed by a ticketing system, or both, because each choice changes who receives the report and how quickly it is logged. Delivery is fixed-scope, and the quote follows from that written scope, so the reader should ask for the deliverables to be listed line by line.

DeployOpen then hosts and configures the intake and triage tooling inside the client's own cloud accounts, data center or air-gapped network. For vulnerability records, this commonly means a self-hosted findings manager such as DefectDojo, which the project documents as importing findings from more than 500 security tool report formats and deduplicating them with per-tool hashcode fields. Reporters can reach the team through the published contact address, and the single point of contact described in Article 13(17) can be backed by the same queue so that email, web form and other channels all end in one record. The reader should confirm that each channel is monitored, that access to reports is limited to named roles, and that the reporting path matches the coordinated disclosure policy the organization already publishes.

DeployOpen prepares the documentation that Annex VII point 2(b) asks for: the contact address, the channel description, the triage procedure and the records showing that reports were received and handled. The client keeps ownership of the controls and of every acknowledgment sent to a reporter. DeployOpen supports the internal team through configuration handover, walkthroughs and, where contracted, retainer support for upgrades and testing of the intake path. DeployOpen does not issue assessment outcomes, attestations or certifications. An independent auditor, assessor or certification body makes that determination, so the client should confirm with its conformity assessment provider which records and test results it expects to review.