CRA component cockpit — tech-stack inventory for the Cyber Resilience Act
Derives an SBOM-style component list from the tech stack detected during the scan, flags potentially outdated components with CVE references (heuristic), exports CycloneDX and tracks the CRA deadlines. A preparation aid — not an assurance of compliance.
The Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to maintain, among other things, a traceable overview of their components and to handle vulnerabilities. The CRA component cockpit gives you a practical starting point: it derives an SBOM-style component list from the tech stack detected during the website scan — server, CMS, plugins, libraries, frameworks, CDN, WAF, payment and consent services — and flags potentially outdated or end-of-life components with CVE references. Important: this assessment is based on an offline heuristic from detected versions, not on a real dependency scan of your source code — it cannot detect distribution backports or individual patches.
CRA component cockpit — tech-stack inventory for the Cyber Resilience Act features
Component inventory from the scan
The tech stack detected during the website scan automatically yields a component list — grouped by server, CMS, plugin, library, framework, CDN, WAF, payment, consent and font, each with a detected version where visible.
Outdated, EoL and CVE references (heuristic)
Components whose detected version is considered potentially outdated or end-of-life (EoL) are highlighted — with a severity, possible CVE references and a "fixed in" note where available. A heuristic, not a binding vulnerability assessment.
CycloneDX export (SBOM-style list)
Export the component list as CycloneDX 1.5 JSON (.cdx.json) — an open, widely used SBOM format. This gives you a machine-readable, SBOM-style component list as a working basis and discussion document.
Scope: does the CRA apply to you?
A question up front clarifies whether you place a product with digital elements on the market — desktop program, mobile app, browser extension, device with its own software, on-premise variant or remote data processing as part of a product. Anyone operating only a website or pure software as a service answers no: the cockpit then hides the deadlines and stops sending deadline reminders. The component list stays usable either way.
CRA deadlines with escalation banner
The cockpit tracks the two central CRA dates: the reporting obligations from 11 September 2026 and full application from 11 December 2027. A banner escalates from info to warning to critical as a deadline approaches; a date that has already passed is shown as in force instead of glowing red permanently.
Acknowledge & notes per component
You can acknowledge a finding per component (for example after a verified distribution backport) and add a note — acknowledged entries stay visible but can be undone. This documents your review status in a traceable way.
Overview across all websites
An overview summarises the component count, the number of potentially outdated components and the worst severity per website — so you can see where the preparation need is greatest.
How it works
Let your website be scanned
During the regular scan, XICTRAQ detects your website tech stack. From this, the cockpit derives an SBOM-style component list — without access to your source code or dependency files.
Review and classify the findings
See the detected version, outdated and EoL references and possible CVE links per component. Where a distribution backport or an individual patch is in place, acknowledge the finding with a note.
Export and keep deadlines
Export the component list as CycloneDX JSON for your records and keep an eye on the CRA dates 11 September 2026 and 11 December 2027 via the deadline banner.
Both key dates in view
A deadline banner in the cockpit escalates from info to warning to critical as the respective date approaches.
From this date, the reporting and notification obligations of the Cyber Resilience Act apply for actively exploited vulnerabilities and severe incidents.
From this date, the requirements of the Cyber Resilience Act apply in full to affected products with digital elements.
Component categories from the tech stack
The CRA component cockpit derives the component list from the externally detected tech stack and assesses versions with an offline heuristic. It does not perform a real dependency scan (for example via a composer.lock) and does not query a vulnerability database live. Markings are "potentially affected", may be inaccurate due to distribution backports or individual patches and are to be understood as a review hint. The export is an SBOM-style component list, not a complete software bill of materials. Compliance with the Cyber Resilience Act is not assured; the applicable requirements and a review by qualified experts are decisive.
Frequently Asked Questions
Does the CRA component cockpit make me CRA compliant?
What is the Cyber Resilience Act (CRA)?
How reliable are the CVE and outdated references?
Is the CycloneDX export a real SBOM?
Which components does the cockpit detect?
Which plan includes the CRA component cockpit?
The security scan detects the tech stack from which the cockpit derives the component list — plus SSL, security headers and third-party scripts as ongoing evidence.
Data protection and the CRA interlock: the GDPR check examines trackers, cookie consent and mandatory pages — a sensible complement to your CRA preparation.
The CRA and NIS2 pursue related goals around cybersecurity and the supply chain. The NIS2 readiness module structures your preparation status across ten measure areas.