A product security information page can turn scattered CRA user information into one maintained security hub. It works best when it points users to authoritative version-specific instructions and advisories while keeping the core Annex II facts easy to find without forcing users through a generic support portal.
Treat the Page as an Organising Layer, Not a New Legal Document
The CRA requires Annex II information but does not prescribe a document titled product security information page. Manufacturers can use a page, portal or product-security section to organise the required information, provided the statutory content remains clear, accessible and connected to the product.
- Use Annex II as the content baseline.
- Do not invent a new statutory form.
- Keep product information easy to locate.
- Link to detailed instructions where appropriate.
Put Product Identity at the Top
Users should immediately know which product the page covers. Include the product name, type and relevant version, model or build identifiers. If one page covers several supported branches, present the scope clearly so users can find the instructions and support information that apply to their version.
- Product name and type.
- Version or model scope.
- Supported branches.
- Links to version-specific documentation.
Make Manufacturer and Vulnerability Contacts Prominent
Annex II points 1 and 2 require manufacturer contact information and the single point of contact for vulnerability information together with the CVD policy location. A product security page is a natural place to make those routes easy to find without mixing vulnerability reporting into ordinary billing or sales support.
- Manufacturer contact information.
- Vulnerability reporting contact.
- CVD policy link.
- Clear separation from ordinary support.
Summarise Intended Security Use and Known Risks
The page can summarise the intended security environment, important security properties and material known or foreseeable circumstances that can lead to significant cybersecurity risks. Detailed configuration guidance can live elsewhere, but the security page should point users to the authoritative instructions needed to operate the product safely.
- Intended security environment.
- Important security properties.
- Material risk-producing circumstances.
- Links to secure configuration guidance.
Show Security Support and End-of-Support Information Clearly
Annex II point 7 requires the type of technical security support and the support end date. Article 13(19) also requires the date to be visible at purchase, so an online security page should complement rather than replace purchase-time disclosure. Keep current support status and end dates easy to locate for each covered version.
- Technical security support type.
- Support end date.
- Version-specific support status.
- Migration information where relevant.
Create a Clear Security Update Section
The page should point users to security advisories, available security updates and installation instructions. Where products have several supported branches, users should be able to distinguish affected and corrected versions without navigating unrelated feature release notes.
- Security advisory index.
- Affected and fixed versions.
- Update installation instructions.
- Historical update access.
Include Secure Decommissioning Guidance
Annex II point 8(d) requires secure decommissioning information and secure removal of user data. The product security page can link to product-specific retirement instructions covering credentials, stored data, cloud associations, integrations and ownership transfer where those elements apply.
- Data removal instructions.
- Credential revocation.
- Cloud or integration removal.
- Ownership-transfer guidance where relevant.
Use Durable URLs and Preserve Historical Versions
Article 13(18) requires online Annex II information to remain accessible, user-friendly and available for at least 10 years after the product is placed on the market or for the support period, whichever is longer. Product-security pages should therefore use durable URLs and preserve historical version information instead of silently replacing all old documentation with the newest release.
- Use stable product-security URLs.
- Preserve historical supported information.
- Avoid broken advisory and update links.
- Maintain version selectors or archives.
Assign Ownership and a Review Trigger
A product security page can become stale if no team owns it. Manufacturers should define who updates support dates, vulnerability contacts, advisory links, secure-use instructions and product-version information. Release events, support changes and major security changes should trigger review.
- Assign page ownership.
- Review after security-relevant releases.
- Review when support dates change.
- Test contact and documentation links periodically.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.