Rockchip Customer-Version FAQ Whitepaper

Document Version: V1.0 (2026-08)

Applicable Audience: Customers developing products destined for the EU market based on Rockchip SoCs

Introduction

The CRA (full name: Cyber Resilience Act, Regulation (EU) 2024/2847) is an EU regulation establishing mandatory cybersecurity requirements for products with digital elements — hardware, software, or combinations thereof. It applies to products with digital elements made available on the EU market in the course of commercial activities, whose intended or reasonably foreseeable use includes direct or indirect, logical or physical data connectivity, except for cases excluded under CRA Article?2.

Rockchip is systematically building CRA compliance capabilities: leveraging the established Product Security Incident Response Team (PSIRT), cooperating with certification bodies to build a vulnerability-handling system, continuously improving the Security Development Lifecycle (SDLC) process, building transparent and traceable software supply chains in new-release SDKs, and collaborating with industry-chain partners to advance long-term-support schemes.

Presented in FAQ format, this whitepaper summarises CRA requirements and Rockchip's supporting capabilities to help customers plan their own compliance roadmaps.

 Table of Contents

Question

1. What is the Cyber Resilience Act (CRA)?

2. Which products are affected by CRA?

3. What are CRA's key dates and enforcement timeline?

4. What are manufacturers' obligations under CRA?

5. What level of security requirements must be satisfied? — Risk-based approach

6. How does CRA classify products? Which category do Rockchip chips belong to?

7. How is Rockchip preparing for CRA and supporting customers?

8. What preparations should customers undertake?

1. What is the Cyber Resilience Act (CRA)?

The CRA (full name: Cyber Resilience Act, Regulation (EU) 2024/2847) is an EU regulation setting mandatory cybersecurity requirements for all products with digital elements — hardware, software, or combinations of both. It governs products sold on the EU market regardless of country of origin.

For products falling under CRA scope, compliance with CRA essential cybersecurity requirements is a prerequisite for affixing the CE marking. For breaches of core essential cybersecurity requirements or key manufacturer obligations, administrative penalties may reach up to EUR?15?million or 2.5?% of global annual turnover (whichever is higher). Separate lower penalty ceilings apply for other categories of infringements.

2. Which products are affected by CRA?

A product falls within CRA scope when all of the following judgement criteria are met:

3.  What are CRA's key dates and enforcement timeline?

?11?June?2026: Chapter IV (Notified Bodies for conformity assessment) enters into force.

?11?September?2026: Article?14 reporting obligations enter into force (applies to all in-scope products regardless of when they were placed on the market).

For actively-exploited vulnerabilities: early warning no later than 24?hours upon awareness; full vulnerability notification within 72?hours; final report no later than 14?days after corrective or mitigating measures are available. For severe incidents, final reporting follows Article?14(4)(c). Reports shall be submitted via the single CRA reporting platform (Article?16), notifying both ENISA and the coordinating CSIRT designated per Article?14(7).

?11?December?2027: Full enforcement.

All products newly placed on the EU market on or after this date must achieve full CRA compliance. Products already placed on-the-market before this date are exempt from full Annex?I obligations unless they undergo a substantial modification as defined in Article?3(30).

4. What are manufacturers' obligations under CRA?

 1. Core Security Requirements (Annex?I Part?I)

? Secure-by-design and secure-by-default principles

?No known exploitable vulnerabilities when placing the product on the EU market

?Where applicable, satisfy concrete requirements set out in Annex?I Part?I point?2 (a) to (m), covering access control, data protection, attack-surface minimisation etc.

?Annex?I Part?I point?1: design, development and production of products with digital elements shall deliver appropriate cybersecurity safeguards commensurate with risk levels.

 2. Vulnerability-Handling and Support Obligations (Annex?I Part?II)

?Establish ongoing vulnerability-management and incident-reporting mechanisms (continuous lifecycle obligation, not a one-time compliance check)

?Generate Software Bill of Materials (SBOM) in machine-readable format covering at minimum top-level dependencies. CRA does NOT mandate public disclosure of SBOM; SBOM shall be provided to market-surveillance authorities upon reasoned request. 

?Conduct regular, effective security testing and reviews

?Timely vulnerability remediation and provision of security updates; separate security updates from feature updates where technically feasible

?Publish security advisories containing vulnerability descriptions, identifiers, scope of impacted products, severity ratings and remediation guidance

?Formulate and publish a Coordinated Vulnerability Disclosure (CVD) policy

?Provide designated contact points for vulnerability submissions

 3. Reporting Obligations (Article?14)

?Continuous lifecycle obligation: report security incidents to ENISA / Member-State CSIRTs throughout the product lifetime

?Timing requirements: 24-hour early warning → detailed notification within 72?hours → final report (14?calendar days for actively-exploited vulnerabilities / one calendar month for severe incidents).

?Effective date: 11?September?2026 (refer to Section?3 timeline).

 4. Support Period (Article?13(8))

?In principle the support period shall be no shorter than 5?years. A shorter period is permitted only where the product's reasonably-expected service life is inherently less than five years. Determination shall further consider reasonable user expectations, product nature, operating environment, end-of-support timelines for key third-party components and established practice for comparable products. All justification for support-period determination must be retained within technical documentation. 

?Legal note: CRA does not define a statutory start-point tied to individual physical device units. Manufacturers shall document all factors used to set the support period in technical documentation.

?Rockchip conservative planning guidance (interpretive business guidance, not explicit CRA statutory text): for continuously-sold product models, support obligations may be planned to persist until 5?years after the last batch is placed on the EU market. 

?Support periods must be defined, publicly disclosed and documented for the product. Vulnerability handling and security updates matching the declared duration shall be maintained.

?End-of-support dates must be communicated to end-users; notifications shall be issued ahead of expiry where technically feasible.

 5. Additional Obligations

?Fully document risk-driven security decisions (risk analyses, workflows, rationale for component selection; refer to Section?5).

?CE-mark conformity assessment: The CE marking may only be affixed after completion of cybersecurity compliance evaluation.

?Software supply-chain transparency: SBOM obligations apply to all in-scope products with digital elements, not limited to high-risk products.

?End-user communication: inform users of residual risks and recommended mitigation measures (impacts product-specification documentation and user manuals).

5. What level of security requirements must be satisfied? — Risk-based approach

1. CRA does not impose uniform technical baselines or mandate specific functions or technical implementations. It defines outcome-oriented requirements in Annex?I. Implementation depth is determined by the manufacturer according to risk and must be fully documented:

    - Identify risks relevant to the product

    - Deploy mitigation measures proportionate to identified risks

    - Communicate residual risks and mitigation strategies to end-users

All security decisions must be risk-based and well-documented. Documentation shall include risk analysis records, implemented workflows and rationale for component choices.

2. Core principle: Proportionality

Scenario illustration: A product which is neither important nor critical yet deployed in critical-infrastructure or high-exposure environments, where compromise could result in severe harm. Even though the product is not subject to formal assessment for Critical-class products, mitigation measures must still match real-world risk exposure. Hardening controls (disable debug interfaces, full-chain secure-boot validation, minimise attack surface etc.) shall be applied rather than merely satisfying minimum baseline criteria.

Implication for customers: A Class?I classification for a chip does not mean end-products built using that chip need only meet minimum regulatory thresholds. Actual deployment scenarios and threat landscape define required security-investment depth.

6. How does CRA classify products?

Note: Official CRA terminology: products which are neither important nor critical products with digital elements (Annex?III / Annex?IV). Classification assessment shall reference Annex?III, Annex?IV and Implementing Regulation (EU)?2025/2392.

Critical reminder: Chip classification ≠ end-product classification. An end-product may only receive elevated classification when its core functions exactly match Annex?III descriptions (e.g. firewall functionality). Final classification is determined by the form-factor and intended usage of the complete end-product. Rockchip's classification matrix serves only as reference input; customers remain fully responsible for compliance determination for their own finished goods.

7. How is Rockchip preparing for CRA and supporting customers?

a) Vulnerability Response: RKPSIRT

Rockchip has established its Product Security Incident Response Team (RKPSIRT), responsible for intake, investigation, remediation and public disclosure of security vulnerabilities affecting Rockchip chips, SDKs and BSPs.

Rockchip service windows (official operational start: September?2026):

Vulnerability-Reporting Window: psirt@rock-chips.com (PGP-encrypted submissions supported)|

Security-Advisory Window: Security-advisory webpage + targeted customer notifications

Response timelines:

Statutory incident reporting per Article?14 for actively-exploited vulnerabilities and serious security events:

24-h early warning

72-h detailed notice

final report: 14?days for vulnerabilities

one month for severeincidents

b) Compliance-System Build-up (in partnership with certification bodies)

Rockchip has selected compliance-service partners and is building enterprise-level workflows and product-compliance systems aligned with prEN?40000-1-2 /1-3 /1-4 (CRA harmonised-standard suite), prEN?50765 (microchip-security standard), and IEC?62443-4-1. Presumption-of-conformity effect only applies after references are formally published in the EU Official Journal.

- Security-development lifecycle (SDLC): 

Aligned with prEN?40000-1-2 (secure-by-design requirements); pursuing IEC?62443-4-1 process certification.

- Vulnerability-handling system: 

Aligned with prEN?40000-1-3, covering vulnerability-incident policies, CVD policy, and end-to-end workflows: intake → validation → remediation → publication → post-release monitoring.

- Security-update mechanisms: 

Aligned with prEN?40000-1-4 (security-update requirements).

- Chip-level product security: 

Aligned with prEN?50765 (vertical microchip security standard covering CRA chip-layer obligations).

- Vulnerability-intelligence monitoring: 

Rockchip will ingest feeds including EUVD (EU Vulnerability Database), NVD, upstream open-source advisories and third-party supplier bulletins.

c) Chip-Level Security Capabilities

These capabilities map against CRA Annex?I Part?I clauses: (b) secure-by-default configuration, (c) security updates, (d) access control, (e) confidentiality and (f) integrity. Customers may build compliant products on top of Rockchip SDK security frameworks. Customers retain full responsibility for end-product threat-modelling, configuration, integration validation, risk assessment, technical-file compilation and conformity-assessment activities.

d) Software-Supply-Chain Transparency (SBOM)

- CRA-compliant products must be built upon Rockchip's new-generation SDK releases built on recent LTS code bases. Exact version prerequisites are available via Rockchip customer contacts.

- New-generation SDKs will ship with built-in SBOM-generation utilities plus user documentation. Machine-readable SBOM outputs follow SPDX / CycloneDX formats and satisfy prEN?40000-1-3 PRE-7 requirements, including component names, versions, producers, dependency relationships and unique identifiers.

- SBOM use-cases: component-level impact analysis upon new CVE disclosures, assembly of complete end-product SBOMs and compliance audits. Baseline SDK SBOM artefacts are retrievable on-demand via the customer portal (not publicly downloadable, consistent with mainstream industry practice).

Rockchip Support Policy:

Legacy SDK releases may not provide SBOM outputs, vulnerability monitoring patches or long-term maintenance sufficient for CRA compliance evidence. Customers continuing to deploy legacy SDKs assume full responsibility for supplementary analysis and maintenance.

Migration Paths for Legacy Products

For existing products developed based on the legacy-version SDK, it is recommended as following:

?Legacy products still to be placed on the EU market after December?2027:

Rebuild firmware on new-generation SDK and bring under CRA compliance scope

?Short-lifecycle products with all market release completed before December?2027:

Full Annex?I compliance is not required (no retroactivity). Nevertheless, statutory Article?14 reporting obligations apply starting September?2026; security-baseline evaluation is strongly recommended.

Definition of “Placing on the Market”

CRA obligations are anchored to the event of placing on the market (Article?3(21)): this is a unit-level event for each distinct device or software version at its first making-available within the EU market, not a model-wide event. “Model launched in 2027” does not grant blanket exemption for all units of that model.

Note: “First making available on the EU market” is not identical to physical import or customs clearance. Customers shall preserve contracts, invoices, import-delivery records, ownership-transfer evidence, serial-number logs and inventory documentation to prove exact placing-on-market dates for individual product units.

e) Support Period

Aligned with CRA Article?13(8): minimum 5-year support period based on documented reasonable-expected product service-life.

- Rockchip will publish product supply lifecycles and formal cybersecurity-support periods in due course.

- New-generation SDK security-patch cadence is synchronised with RKPSIRT security-advisory releases.

- Rockchip collaborates with strategic partners on kernel LTS initiatives to extend maintenance windows for open-source components.

- End-of-support advance-notification mechanisms are provided to help customers fulfil Article?13-related end-user-information obligations.

f) End-to-End CRA Lifecycle Support from Rockchip

Rockchip's CRA support covers all stages of customer product compliance:

g) Division of Responsibilities

8. What preparations should customers undertake?

Rockchip recommends customers follow these implementation steps:

1. Inventory product portfolio: Identify products shipped to the EU market; determine CRA classification (Default / Class?I / Class?II). Conduct risk assessment for real-world deployment scenarios applying the proportionality principle described in Section?5.

2. Adopt new-generation SDKs: Confirm use of new-generation SDK releases for CRA-targeted projects to obtain SBOM tooling and security-framework support. Evaluate migration options for existing legacy-based products.

3. Build internal vulnerability-management workflows

    - Establish a public vulnerability-reporting contact point (e-mail or web submission form).

    - Draft and publicly release a Coordinated Vulnerability Disclosure (CVD) policy.

    - Establish secure communication channels with RKPSIRT (including PGP-encrypted message support).

4. Plan post-market statutory obligations: Define vulnerability-handling workflows, prepare access to ENISA reporting channels (must be ready before 11?September?2026), finalise security-update rollout processes.

5. Confirm support-period commitments: Comply with Article?13(8) minimum-5-year-related obligations; align chip and SDK supply-maintenance timelines with Rockchip.

6. Engage Rockchip CRA liaison channels: Obtain SDK security documentation, SBOM reference samples and documented joint vulnerability-handling procedures.

Appendix: Consolidated Key Timeline

August?2026:

           RKPSIRT vulnerability-handling framework and CVD policy released

?September?2026

① CRA statutory Article14 reporting obligations enter into force (ENISA reporting rules: 24-h early warning /72-h detailed notice / final report: 14?days for vulnerabilities / one month for serious incidents)

② Rockchip security-advisory portal and dedicated customer-liaison channels go-live

③ Rockchip SoC CRA classification matrix published

?Q3?2027

① Completion of Rockchip CRA enterprise-process and product-compliance system (aligned with prEN?40000-1-2/3/4 and prEN?50765)

② IEC?62443-4-1 security-development-process certification achieved

?11?December?2027:

Full CRA enforcement. All products newly placed on the EU market from this date must achieve complete CRA compliance.

Disclaimer

This document is published by Rockchip for customer-reference purposes only. It does NOT constitute legal advice, nor any warranty or undertaking by Rockchip regarding CRA compliance for customer-end products. Descriptions of Rockchip product capabilities and support policies are subject to formal contracts, product-security advisories and controlled-release documentation. Legal interpretation of the CRA, related delegated and implementing acts rests exclusively with the Court of Justice of the European Union, European Commission and competent national regulatory authorities.

Contact Information

Vulnerability Reports: psirt@rock-chips.com (PGP-encrypted submissions supported)

CRA Compliance Enquiries: cra@rock-chips.com

CRA Commercial Liaison: contact your assigned Rockchip sales representative