CRA product architecture documentation should explain how the real marketed product is assembled and how its security-relevant components interact. A component list alone is not enough. The architecture record should make important interfaces, data paths, dependencies, trust boundaries, remote services and privileged components understandable so that risks, controls and security tests can be traced to the correct part of the product.
Annex VII Expressly Refers to System Architecture
Annex VII point 2(a) requires necessary information on the design and development of the product with digital elements. Where applicable, that information includes drawings and schemes and a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing. Architecture documentation is therefore more than an optional visual aid where it is needed to explain the product. It should allow a qualified reviewer to understand the important component relationships underlying the manufacturer's cybersecurity conclusions.
- Document necessary design and development information.
- Include relevant drawings and schemes.
- Explain system architecture where applicable.
- Explain how software components relate.
- Explain how components integrate into overall processing.
Start With the Product Boundary
Architecture documentation should identify what is inside the assessed product boundary and what is an external dependency. This is especially important for connected products combining device software, cloud services, mobile applications, APIs and third-party infrastructure. If the boundary is ambiguous, security responsibilities and risk assumptions can also become ambiguous. The documented boundary should remain consistent with the intended purpose, cybersecurity risk assessment and conformity assessment scope.
- Identify product components.
- Identify manufacturer-operated remote components.
- Identify external services.
- Identify third-party dependencies.
- Identify interfaces crossing the product boundary.
Document Major Software Components
Identify the software components that materially affect the product's operation or cybersecurity. Depending on the architecture, these can include services, applications, firmware modules, libraries, databases, background processes, API layers, update agents and management components. The architecture record should show relevant relationships rather than duplicate the complete software bill of materials. The SBOM answers what software components and dependencies are present, while architecture documentation explains how important components interact and participate in processing.
- Applications and services.
- Firmware modules.
- Databases and storage services.
- Update components.
- Management components.
- Security-relevant third-party components.
Include Hardware Components Where Security Depends on Them
For hardware products, cybersecurity can depend on processors, secure elements, storage, network interfaces, debugging ports, sensors, controllers or other physical components. Architecture documentation should identify hardware elements where they affect trust boundaries, key protection, boot integrity, communications, physical access or update behaviour. The objective is not to produce a manufacturing drawing of every physical part but to preserve the hardware context required to understand cybersecurity controls.
- Processors and controllers.
- Security or trusted hardware.
- Persistent storage.
- Network interfaces.
- Debugging interfaces.
- Hardware roots of trust where used.
Document Component Relationships
Annex VII specifically refers to explaining how software components build on or feed into each other. The architecture should therefore show meaningful dependencies and communication relationships. A reviewer should be able to determine which component calls another service, where data are stored, which component performs authentication, which service controls updates and which component processes untrusted input. These relationships help identify attack paths and determine where security controls are expected to operate.
- Service dependencies.
- API relationships.
- Authentication dependencies.
- Storage relationships.
- Update relationships.
- Security-service dependencies.
Document External Interfaces
External interfaces are important to both risk assessment and Annex I attack-surface analysis. Architecture documentation can identify network ports, APIs, web interfaces, wireless protocols, file-import mechanisms, hardware connections, administrative channels and cloud integrations. Record which component terminates the interface and what trust or authentication assumptions apply. Interfaces that are disabled by default or only present in particular product editions should be marked accordingly.
- Network services.
- Public and private APIs.
- Administrative interfaces.
- Wireless interfaces.
- File and data-import interfaces.
- Hardware or peripheral interfaces.
Show Important Data Flows
Data-flow documentation can show where security-sensitive information enters, moves through and leaves the product. Relevant flows can include credentials, personal or operational data, update packages, commands, configuration, logs and cryptographic material. The flow should identify important transformations and protection boundaries where useful. This supports analysis of confidentiality, integrity, data minimisation and secure transfer requirements without requiring every low-level program variable to be documented.
- Credential flows.
- Sensitive data flows.
- Administrative command flows.
- Update package flows.
- Logging and monitoring flows.
- Cryptographic key flows where relevant.
Identify Trust Boundaries
Trust boundaries indicate where the product crosses between different security assumptions or privilege levels. Examples include internet-to-service boundaries, user-to-administrator boundaries, application-to-operating-system boundaries, device-to-cloud boundaries and isolated security components. Documenting these boundaries helps threat modelling and attack-scenario analysis because controls such as authentication, authorisation, validation or cryptographic protection often operate at the boundary.
- External network boundaries.
- Privilege boundaries.
- Process boundaries.
- Device-to-cloud boundaries.
- Security-domain boundaries.
- Third-party service boundaries.
Identify Privileged and Security-Critical Components
Some components have greater security significance because compromise can affect many other parts of the product. Examples can include identity services, update agents, key-management services, boot components, administrative services and central configuration systems. Marking these components in the architecture helps reviewers understand why certain threat scenarios and verification activities receive greater attention. It also supports least-privilege and exploitation-mitigation analysis.
- Authentication services.
- Authorisation services.
- Update infrastructure.
- Key-management components.
- Administrative components.
- Security monitoring components.
Document Remote and Cloud Components
Products with digital elements can depend on remote services for authentication, configuration, updates, storage or core functionality. Architecture documentation should identify remote components relevant to the product's cybersecurity and explain their relationship to local software. This is especially important where product availability or security changes when the remote service is unavailable or compromised. The architecture should distinguish manufacturer-controlled services from external services whose behaviour is an environmental dependency.
- Manufacturer-operated cloud services.
- Authentication providers.
- Update services.
- Remote management services.
- External third-party services.
- Connectivity and dependency assumptions.
Connect Architecture to the Cybersecurity Risk Assessment
Architecture documentation provides the technical structure used by threat and risk analysis. Risk records can reference component and interface identifiers rather than describing the architecture again. When a risk involves an exposed API, privileged process or update service, the architecture should make that element identifiable. This relationship also helps detect stale assessments because an architecture change can reveal that an earlier threat model or control assumption no longer matches the product.
- Use stable component identifiers.
- Link risks to architecture elements.
- Link interfaces to attack scenarios.
- Link assets to data flows.
- Trigger reassessment after material architecture changes.
Connect Architecture to Annex I Controls
Architecture can show where Annex I security properties are implemented. Authentication components can support protection from unauthorised access. Encryption boundaries can support confidentiality. Update verification can support integrity and vulnerability handling. Isolation boundaries can support incident-impact reduction. Logging pipelines can support security-related information. This does not mean the architecture diagram alone proves compliance, but it provides the technical map linking requirements to design and verification evidence.
- Identify authentication and access-control components.
- Identify confidentiality controls.
- Identify integrity controls.
- Identify resilience components.
- Identify update components.
- Identify logging and monitoring architecture.
Version Architecture Documentation With the Product
Architecture evidence should identify the product version or release baseline it describes. New services, interfaces, dependencies or deployment options can materially alter cybersecurity risk. A diagram labelled current architecture without release context can become misleading after several product changes. Maintain revision history or another controlled mapping between product releases and architecture documentation.
- Document architecture version.
- Identify corresponding product release.
- Record material architecture changes.
- Retain relevant historical versions.
- Review dependent risk and test evidence.
A Practical CRA Architecture Documentation Set
A practical evidence set can contain a product-boundary diagram, component architecture, deployment architecture, interface inventory, important data-flow diagrams, trust-boundary view and description of security-critical components. The CRA does not prescribe one diagram notation. The required depth depends on the product. The test is whether the documentation gives enough necessary information to understand the design and development of the product and support the risk and conformity evidence.
- Product-boundary diagram.
- Component architecture.
- Deployment architecture.
- Interface inventory.
- Security-relevant data flows.
- Trust boundaries.
- Security-critical component description.
- Architecture version history.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.