Enterprise customers often need more operational detail than a consumer quick-start guide, but the legal baseline is still Annex II. A useful enterprise package brings product identity, security assumptions, vulnerability contacts, support dates, update procedures, risk information and integration guidance together without confusing user documentation with the manufacturer's internal Annex VII technical file.
There Is No Separate Enterprise-Only Annex II
Article 13(18) applies the Annex II information and instruction requirements to products with digital elements generally. The CRA does not say that enterprise products use a different Annex II. Manufacturers can tailor the presentation to enterprise users, but the required user information remains the legal baseline.
- Use Annex II as the baseline.
- Tailor presentation to enterprise operations.
- Do not omit required content because the customer is sophisticated.
- Avoid inventing an enterprise-only statutory document name.
Make Product and Version Identification Precise
Enterprise customers can operate several versions, deployment models and hardware revisions at once. Annex II product-identification information should therefore be precise enough for security teams to map advisories, updates and support status to the assets they actually manage.
- Product name and type.
- Version or build identifiers.
- Deployment model where relevant.
- Hardware revision where relevant.
Document the Intended Security Environment
Enterprise deployment guides should explain the security environment assumed by the product, including network boundaries, identity dependencies, administrative roles, supported integrations and other conditions relevant to secure operation. This directly supports Annex II point 4 and helps security architects understand how the product fits their environment.
- Network assumptions.
- Identity and access assumptions.
- Administrative trust boundaries.
- Supported integrations and dependencies.
Include Known Risk-Producing Conditions
Annex II point 5 applies equally to enterprise products. Documentation should identify material circumstances that can create significant cybersecurity risks, such as unsafe public exposure, insecure trust relationships, unsupported extensions or operation outside the intended architecture.
- Known risky deployment conditions.
- Foreseeable misuse.
- Unsupported security-sensitive configurations.
- Recommended safer alternatives.
Make Vulnerability Reporting Operationally Useful
Enterprise security teams need a clear route for reporting vulnerabilities. The documentation should identify the single point of contact and CVD policy location required by Annex II point 2. Where customers use security operations or procurement portals, the manufacturer can repeat the contact there while keeping one authoritative external route.
- Single vulnerability contact.
- CVD policy location.
- Product and version details reporters should provide.
- Durable contact information.
State Security Support and Update Expectations
Enterprise customers often need lifecycle information for asset planning. Annex II point 7 requires the type of technical security support and the support-period end date. Documentation should also explain the security-update process and where advisories and installation guidance are published.
- Security support type.
- Support end date.
- Security-update channel.
- Advisory location.
Provide Integration Information Where the Product Is Intended for Integration
Annex II point 8(f) requires information necessary for the integrator to comply with Annex I cybersecurity requirements and Annex VII documentation requirements where the product is intended for integration into other products with digital elements. Enterprise integration documentation can therefore include security assumptions, interfaces, update dependencies and technical constraints that affect the combined product.
- Security assumptions for integration.
- Relevant interfaces.
- Dependency and update requirements.
- Information needed for the integrator's documentation.
Keep Enterprise User Documentation Separate From Annex VII Technical Documentation
Enterprise customers may request detailed security evidence, but Annex II user information and Annex VII technical documentation are not the same thing. Manufacturers can share appropriate evidence under commercial or security controls without assuming that the complete internal technical file must be published to every customer.
- Keep Annex II user information accessible.
- Control sensitive internal evidence appropriately.
- Keep shared evidence consistent with the technical file.
- Avoid exposing unnecessary security-sensitive details.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.