Product Capabilities & Technical Architecture | CRA Direct

1. Purpose

CRA Direct helps manufacturers of products with digital elements run the operational side of EU Cyber Resilience Act compliance: product registration, SBOM evidence collection, vulnerability triage, human review, Single Reporting Platform submissions, and audit evidence.

The product follows a straightforward principle: automation can prepare, prioritise, validate, remind, and submit, but legally meaningful decisions stay under human control and are preserved in an audit trail. Compliance evidence is treated as a regulated system of record — SBOMs, decisions, notifications, and audit events are linked, retained, and independently verifiable.

2. Primary Users And Authentication

CRA Direct uses Zitadel for single sign-on. User roles map directly to platform permissions:

• Security and compliance reviewers triage vulnerabilities, record VEX evidence, prepare SRP drafts, and request approval.
• Approvers review finalized evidence and payloads before submission to the SRP.
• Auditors inspect read-only evidence, audit logs, and submission history.
• Organization administrators manage service keys, products, SBOM evidence, and workspace settings.
• Platform super-admins onboard organizations and monitor tenant status across the platform.

This keeps responsibilities separate — the people who prepare evidence are different from those who approve it, which strengthens accountability for regulated reporting.

3. Workspace And Organization Management

Organization Workspace

Each organization gets its own workspace containing products, SBOMs, vulnerability findings, review cases, SRP workflows, notifications, and audit evidence. Legal hold status is visible on organization and workspace views so teams know when evidence must be preserved regardless of normal retention policies.

During onboarding, the platform can auto-provision Zitadel accounts for compliance and security contacts, assigning appropriate roles without manual identity provider configuration.

Organization Profile

The profile stores the business and regulatory data used in submissions: legal name, entity type, registration number, country, registered address, compliance and security contacts, vulnerability disclosure policy URL, main-establishment Member State for Article 14(7) routing, and SBOM retention policy. Incomplete routing information is flagged because missing main-establishment data can block SRP readiness.

Platform Administration

Super-admins can onboard organizations through a guided flow, review tenant product counts and registration status, edit organization profiles, and navigate from onboarding directly to first product registration.

4. Dashboard, Roadmap, And Work Prioritisation

The Overview dashboard gives teams a single view of product coverage, SBOM volume, open vulnerabilities, pending reviews, upcoming deadlines, and readiness gaps. It highlights the next action — whether that is reviewing overdue cases, triaging critical vulnerabilities, completing onboarding, or uploading SBOM evidence.

Three Explicit Platform Roles

Every compliance task is assigned to one of three roles, ensuring clarity of scope:

Role	Count	Platform Action	Manufacturer Responsibility
Handled Here	24 tasks (30.4%)	Owns the operational workflow. Progress is derived from reviewed platform records (scope decisions, SBOM locking, Article 14 sent stages).	Provide accurate product facts and final accountability approvals.
Assisted Here	51 tasks (64.6%)	Guides the user through obligations, explains controls, lists required evidence, and opens verification workflows.	Perform the substantive engineering, certification, and organizational operations.
Tracked Here	4 tasks (5.1%)	Monitors external developments (CRA standards, notified body capacity, legal updates) and records outcomes.	Review monitoring outputs and adjust internal policies.

Deadline awareness is built into every view, not stored in a separate calendar. CRA clocks for 24-hour early warnings, 72-hour notifications, final reports, intermediate reports, and dissemination-delay requests appear directly in queues, dashboard cards, and workflow pages. Teams see what is overdue, what needs action, and what is coming due without manual tracking.

5. Product Registry

Products are the foundation for all downstream evidence and reporting. Teams register product name, CRA category (standard, important, or critical), security contact, support period, versioning scheme, CE marking status, and vulnerability disclosure policy. Only registered active product versions can receive SBOM evidence; deprecated and end-of-life versions remain visible for audit history.

Product detail pages bring together metadata, versions, context documents, SBOM evidence sets, related SRP submissions, and audit history in one place.

6. Product Documentation And Supporting Files

Users manage product-level documentation from a single Documentation tab on the product detail page, which separates completed CRA deliverables from supporting files used for product-aware analysis.

Supporting files (security architecture, threat models, user manuals, release notes, test reports) apply to all versions or a specific version. Archived files are removed from future analysis context, and original files are retained in Object Storage with secure 5-minute pre-signed links.

Documentation Reminder Scheduler

The scheduler persists the 27-document schedule and coordinates alerts. Notifications distinguish new triggers, drafts awaiting completion, and overdue files. Conditional templates (such as CRA-COND-001 and CRA-COND-002) are marked as internally fulfilled once the corresponding Article 14 stages have been successfully sent to the Single Reporting Platform (SRP).

7. SBOM Evidence And Component Inventory

The SBOM Library accepts CycloneDX (1.4–1.7) and SPDX (2.2, 2.3, 3.0.1) uploads for registered product versions. The API validates files, computes content hashes, archives raw evidence to S3-compatible storage, and locks the evidence set so it can serve as auditable CRA evidence. Duplicate files, format mismatches, and version conflicts are caught during upload.

The library shows evidence status (locked, analyzed, draft, running, failed), baseline and delta scans, component counts, and review handoffs. Component inventory pages connect SBOM files to specific packages and vulnerabilities, with evidence hashes for audit traceability.

Stateless Scanning API

CRA Direct also exposes stateless endpoints that let external tools and CI pipelines evaluate SBOMs without persisting data:

• POST /scan-sbom — accepts a CycloneDX or SPDX SBOM and returns vulnerability findings without creating evidence records.
• POST /scan-purls — accepts up to 500 PURLs and returns matched vulnerability findings.
• POST /triage-stateless — accepts product context and vulnerability findings, returns an AI-assisted triage report.

These are designed for pre-ingest evaluation, CI gating, and external scanner integration without coupling to the platform's evidence lifecycle.

8. Vulnerability Intelligence And Monitoring

Rather than relying on a single third-party scanner, CRA Direct sources vulnerability data directly from authoritative feeds and performs its own component-to-vulnerability matching. This avoids tying the compliance evidence pipeline to any one vendor's data model or update cadence.

Supported intelligence sources:

• OSV — primary vulnerability database via bulk sync and live API lookup
• CISA Known Exploited Vulnerabilities — full catalog with diff-based sync
• FIRST EPSS — exploit prediction scoring
• ENISA EUVD — CVE-to-EUVD mapping

The system runs full baseline scans on locked SBOM sets and impact deltas when new intelligence changes the risk profile of known components. Each intelligence change creates an append-only impact event for audit traceability.

9. AI-Assisted CRA Analysis

Analysis jobs process locked SBOM evidence, vulnerability intelligence, and product context. Results include a bundle-level decision (report candidate, monitor, VEX review, or manual triage), per-vulnerability verdicts with rationale, active exploitation evidence, missing evidence prompts, and recommended next actions.

AI output is draft support only. No-report and not-affected outcomes require human evidence and a final reviewer decision. AI-generated content is validated against the underlying evidence before it reaches a reviewer, and the system falls back to deterministic processing when the model call fails.

10. Vulnerability Triage And VEX Evidence

Reviewers can record VEX evidence with product-specific justifications — not affected, affected, fixed, or under investigation — along with impact statements, action statements, and CSAF-style justifications. The review flow can generate candidate VEX artifacts for approval, and final VEX decisions are locked into the audit history.

11. Human Review Workbench

The Review Workbench organises cases by type: SRP stage submissions, VEX triage, intermediate reports, dissemination-delay requests, and external actions. Behind it is an explicit state machine that moves cases through controlled stages — open, in review, draft generated, submitted for approval, changes requested, rejected, approved, submitted, closed, or archived — depending on case type.

This ensures reviewer and approver responsibilities stay separate, every transition is recorded as audit evidence, and AI output remains a draft until a human completes the relevant workflow step.

12. SRP Submission Workflows

CRA Direct manages Article 14 reporting for both actively exploited vulnerabilities and severe incidents. Vulnerability workflows can start from scanner/AI/VEX analysis or from direct manual intake.

Vulnerability Workflow

• 24-hour early warning under Article 14(2)(a)
• 72-hour notification under Article 14(2)(b)
• Final report under Article 14(2)(c), submitted after a corrective or mitigating measure is available (within 14 days)
• Supplier and maintainer notification tracking for third-party components
• Manual intake for known exploited vulnerabilities

A stuck-mitigation monitor detects when a fix has been available for 14 days without a submitted final report and escalates the workflow so the obligation does not silently expire.

Severe Incident Workflow

• 24-hour early warning under Article 14(4)(a)
• 72-hour notification under Article 14(4)(b)
• Final incident report under Article 14(4)(c), within one month

Two severity criteria sets are supported: SECURITY_IMPACT (active exploitation, loss of confidentiality/integrity/availability) and MALICIOUS_CODE (suspected intentional malicious code, supply-chain compromise indicators).

Workflow pages show stage status across 24h/72h/final submissions, reporting Member State, SRP tracking IDs, user and supplier notification status, and manual attention flags for failed stages.

13. Manual Intake

When a manufacturer already knows a vulnerability is actively exploited and has product-specific evidence, the manual intake flow creates a CRA Article 14(2) workflow without waiting for SBOM analysis upstream. Users capture affected product and version, vulnerability identifiers, awareness time, severity, active exploitation evidence, VEX affectedness verdicts, and market scope.

The same flow exists for severe incidents. During incident review, AI draft assistance can prefill stage content from intake facts, but reviewers still validate and approve the final payload.

14. Intermediate Reports And Dissemination Delay

Intermediate reports let teams respond to CSIRT coordinator requests under Article 14(6) without modifying the core 24h/72h/final obligations. Users register a request from the workflow detail page, which opens a dedicated review case and submits the approved update to the SRP intermediate endpoint.

Dissemination-delay requests capture delay grounds, risk rationale, requested delay window, and disclosure plans. Delay data is included directly in the SRP payload.

15. Activity And Notifications

The Activity Feed gives teams a chronological view of workspace changes — scan completions, triage handoffs, review due dates, approval requests, and SRP outcomes — without entering each workflow.

The Notification Center delivers alerts via email, SMS, Slack, and Teams. Notifications are persisted in the database and processed by a dedicated worker, so failures are visible and retryable rather than silently lost. Deadline reminders follow an escalation cadence (24 hours, 4 hours, 1 hour, 15 minutes before, and at the deadline itself), with deduplication by idempotency key and capped counts to prevent runaway alerts.

16. Service Keys For Automation

Teams can create organisation-scoped API keys for CI pipelines, scanner integrations, and workflow automation. Keys support configurable expiration (30 days, 90 days, 1 year, or no expiration), last-used tracking, and immediate revocation. Three permission scopes are available:

• sbom:ingest — SBOM evidence upload
• stateless:analyze — stateless scanning and triage
• workflow:create — CRA workflow and intermediate report creation

17. Audit Trail And Evidence Integrity

Every significant action — AI analysis, human decision, workflow transition, notification, and SRP submission — is recorded as non-repudiable compliance evidence.

18. Technical Choices At A Glance

CRA Direct is built as a compliance evidence platform rather than just a workflow interface. Key design decisions include:

• Backend-owned Ingestion: The Elysia/Bun API handles SBOM validation, object storage archival, and database locking.
• Immutable Baselines: SBOMs are locked to product versions; vulnerability intelligence updates trigger separate delta analyses instead of modifying baseline records.
• Scanner-Agnostic Intel: Vulnerability data is sourced from OSV, KEV, EPSS, and EUVD feeds, allowing ingestion of any standard CycloneDX or SPDX SBOM.
• Durable Background Workers: Graphile Worker runs vulnerability sync, component scanning, reporting, and alerts with retries and queues.
• Tenant Isolation: Enforced by PostgreSQL Row-Level Security (RLS) policies and organization-bound API service keys.
• AI with Guardrails: AI drafts are validated against evidence rows; errors block reviewer presentation and trigger fallback.
• Zitadel SSO: Auth.js integration with role mapping and auto-provisioning during tenant onboarding.
• DRY_RUN Compliance Mode: Reporter runs in DRY_RUN=true mode to validate the reporting workflow, outputting payload logs instead of sending to the SRP.
• Three-State Circuit Breaker: Outbound calls are protected by a circuit breaker to prevent cascading latency during Single Reporting Platform (SRP) downtime.
• OpenTelemetry Tracing: Configured across service boundaries for span context propagation and trace correlation.
• Performance Targets: Designed for p95 TTFB under 500ms (web) and p95 API latency under 300ms.

19. Current Product Boundaries

• Article 14 SRP reporting is the primary regulated workflow.
• End-user notification status is tracked, but CSAF 2.0 publication is not yet integrated.
• CVSS, EPSS, and severity are prioritisation signals, not standalone Article 14 triggers.
• Product versions must be registered before SBOM upload — ad hoc names are not accepted for locked evidence.
• Final vulnerability reporting starts when a corrective measure is available, not automatically after the 72-hour notification.
• AI output is always draft or decision support until a human records the final business decision.

20. Business Value

• Deadline control — Article 14 clocks are visible across 24h, 72h, final, intermediate, and delay workflows, with reminders that keep the right people informed.
• Lower triage burden — focuses attention on actively exploited and product-relevant vulnerabilities while keeping severity-only noise in monitor paths.
• Connected evidence — links products, versions, SBOMs, VEX decisions, SRP payloads, and audit events in one place.
• Clear accountability — separates reviewer and approver responsibilities and preserves every decision as audit evidence.
• Portfolio visibility — gives security and compliance leaders a single view of risk, readiness, and reporting status.
• Audit confidence — evidence can be exported and verified independently without reconstructing events from email or spreadsheets.