For software, Annex II should be version-aware. Users need to know exactly which release they operate, how to configure and update it securely, which environments are supported, how long the branch receives vulnerability handling and security updates, and how to retire the software and related credentials or data safely.
Identify the Software Product and Version Precisely
Annex II point 3 requires information enabling unique product identification. For software, a commercial name alone may be insufficient. User information can need the version, build, edition, deployment model or release channel so security advisories and update instructions can be mapped to the correct software instance.
- Product name and edition.
- Version or build.
- Deployment model where relevant.
- Release channel where security support differs.
Describe the Supported Security Environment
Software can depend on operating systems, runtimes, browsers, databases, identity providers, cloud environments or network assumptions. Annex II point 4 requires the intended purpose and security environment, so documentation should identify material platform and deployment assumptions needed for secure operation.
- Supported operating systems or runtimes.
- Required identity or network assumptions.
- Supported integrations.
- Security-sensitive deployment limitations.
Document Secure Installation and Initial Configuration
Software instructions should explain the measures users need during installation and commissioning to reach the intended secure state. Depending on the product, this can include package verification, initial administrator creation, secret management, secure defaults, database permissions, network binding or the first security update.
- Trusted installation source.
- Initial administrator setup.
- Security-sensitive configuration.
- Required post-installation update.
Explain Known Risk-Producing Software Configurations
Annex II point 5 applies to software deployments as well. Documentation should explain material circumstances such as unsupported operating systems, unsafe public exposure, disabled authentication, insecure extensions or operation with unsupported dependencies where those conditions may lead to significant cybersecurity risks.
- Unsupported platform use.
- Unsafe service exposure.
- Disabled security controls.
- Unsupported extensions or dependencies.
Make Security Update Instructions Branch-Specific
Software often has several supported release branches. Annex II point 8(c) requires information on how security-relevant updates can be installed. Users should be able to determine which package, repository, channel or version applies to their supported branch and how to verify successful installation.
- Supported update channel.
- Branch-specific package or version.
- Prerequisites and restart requirements.
- Installation verification.
State Support Dates for Software Branches Clearly
Software product families can have different support dates for major branches. Annex II point 7 and Article 13(19) require clear support information. Manufacturers should avoid one broad product date where users actually need branch-specific end dates to understand whether their installed release still receives vulnerability handling and security updates.
- Branch-specific support status.
- Support end date.
- Migration or upgrade path.
- Security advisory location.
Treat Secure Decommissioning as More Than Uninstalling
Annex II point 8(d) requires secure decommissioning and information on secure removal of user data. Software retirement can require revoking API keys, removing service accounts, deleting stored credentials, disconnecting cloud resources, exporting or deleting customer data and removing scheduled jobs or agents in addition to uninstalling the application.
- Revoke credentials and tokens.
- Remove service accounts where relevant.
- Delete or export user data securely.
- Remove integrations and background services.
Keep Online Instructions Available for the Required Period
Article 13(18) requires online Annex II information and instructions to remain accessible and user-friendly for at least 10 years after the product is placed on the market or for the support period, whichever is longer. Software documentation systems should therefore preserve historical instructions rather than redirecting every old version to the current release documentation.
- Preserve historical supported documentation.
- Use durable URLs.
- Keep version selectors understandable.
- Avoid deleting old security instructions prematurely.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.