PLCs, sensors and I/O modules
Sources of data and commands. The gateway must distinguish devices, protocols, flow direction and failure behaviour.
Application case · From product to CRA evidence
CRA Technical Evidence Pack for an industrial connected gateway
We start from an identified release, reconstruct firmware, dependencies, interfaces and the update process, then turn them into evidence, gaps and verifiable engineering actions.
The IG-200 case shows what we assess, what the customer receives and how the work moves from assessment to product remediation.
The case in 60 seconds
An identified product, an actionable technical picture
The value is not the IG-200 model itself, but the chain that can be applied to the customer’s product: identified technical inputs, verifiable evidence and work tied to the next release.
- 1
- versioned HW/SW baseline
- 22
- technical areas considered
- 10
- traceable findings
- 3
- downloadable documents
-
01
Identified input
IG-200 HW Rev. B, IGOS 2.4.1, builds, components, interfaces, configuration and the A/B update path.
-
02
Traceable analysis
The SBOM, exposed surface, boot and recovery, access, logging and vulnerability handling are connected to evidence and findings.
-
03
Operational output
The Scope, Technical Evidence Pack and Management Summary turn gaps into priorities, owners, remediation work and retest criteria.
Pack input · Product baseline
IG-200 · Industrial Edge Gateway
To make the process concrete, the Technical Evidence Pack starts from a precise baseline. Model, revisions, components and configuration define what is assessed and prevent SBOMs and findings from becoming detached from the product.
- Product
- IG-200 Industrial Edge Gateway
- Hardware
- Rev. B · ARM Cortex-A53 · 1 GB RAM · 8 GB eMMC
- Firmware
- IGOS 2.4.1
- Boot and kernel
- U-Boot 2024.01 · Linux 6.1 LTS
- Applications
- Gateway Core 3.2.0 · Web UI 1.8.2
- Interfaces
- 2× GbE · isolated RS-485 · USB service · UART/JTAG
- Protocols
- MQTT 5/TLS 1.3 · Modbus RTU/TCP · REST/JSON
- Update
- Signed A/B images distributed by the release service
- Support period
- 5 years from placing on the market · rationale to be completed
Technical Evidence Pack scope
- Hardware Rev. B, firmware IGOS 2.4.1 and the production configuration.
- Boot chain, Linux image, local services, Web UI, APIs and credentials.
- Open-source components, application dependencies, build and release artifacts.
- OT/IT interfaces, remote updates, logging and vulnerability handling.
System view
Architecture and boundary of the assessed product
The Pack starts from the system rather than firmware alone. Field equipment, gateway and remote services expose trust boundaries, dependencies, update channels and technical ownership.
IG-200 · HW Rev. B
IGOS 2.4.1 on ARM Cortex-A53 with bootloader, embedded Linux, local services, Web UI/API, credentials, logs and an updatable image.
Backend and operations
Broker, APIs, technical dashboard and release repository receive telemetry and support updates and field service.
Assessment boundary: IG-200 HW Rev. B, IGOS 2.4.1, boot chain, included components, local and remote interfaces and product-side release mechanisms. The application backend implementation is excluded.
Evidence traceability
How the Pack turns the product into evidence and actions
Every item is tied to an identified configuration. This chain prevents detached SBOMs, generic findings and fixes that cannot be verified after a new release.
- 1 Product baseline HW revision, intended use, software version and boundaries
- 2 Build provenance Repository, commit, toolchain, configuration and artifacts
- 3 SBOM + surface Components, services, interfaces, privileges and data flow
- 4 Finding + test Evidence, impact, reproducibility and technical priority
- 5 Remediation Owner, change, release, retest and lifecycle traceability
Findings Register excerpt
The register connects each area in the IG-200 baseline to its status, required evidence and technical action. This level of traceability lets the customer understand what is missing and how to intervene.
| Assessment area | Evidence status | Evidence to collect | Technical action |
|---|---|---|---|
| IG200-F-003 IGOS 2.4.1 · SBOM | GAP | Manifests, package locks, build output and a machine-readable SBOM tied to the release. | Generate and version the SBOM and component inventory in the release pipeline. |
| IG200-F-001 IGOS 2.4.1 · A/B update | GAP | Image format, signing, HW compatibility, boot state, health checks, recovery and logs. | Define the trust chain, version policy, rollback and fault-injection tests. |
| IG200-F-002 HW Rev. B · UART/JTAG | GAP | UART/JTAG state, service modes, protections and the technical-access procedure. | Disable, authenticate or govern access according to the support model. |
| IG200-F-008 Gateway Core 3.2.0 · Network | PARTIAL | Listening sockets, ports, protocols, APIs, privileges, certificates and firewall rules. | Reduce exposed surface, separate roles and document secure configuration and hardening. |
| IG200-F-007 Product release · Vulnerability gate | GAP | Known-vulnerability review result, affected versions, justified exceptions and release approval. | Add a repeatable gate with a checklist, owner, blocking criteria and decision evidence. |
| IG200-F-004 Product lifecycle · Vulnerabilities | GAP | Policy, reporting contact, triage, affected assets, SLAs and fix communication. | Define the process, ownership, register and link between vulnerabilities and releases. |
IG-200 sample document set
Download the Technical Evidence Pack structure
Three coordinated English documents show how scope, technical analysis and management decisions are tied to the same product baseline.
Main technical document
CRA Technical Evidence Pack
Architecture, SBOM, attack surface, updates, findings, references and evidence mapping applied to the baseline.
Management Summary
An executive view of gaps, priorities, remediation roadmap and decisions required from the product team.
Technical Assessment Scope
Scope, IG-200 baseline, required inputs, included activities, exclusions and acceptance criteria.
Usage notice: The files contain illustrative data and every page carries the watermark “DEMONSTRATION SAMPLE — NOT VALID CRA CONFORMITY EVIDENCE”. They do not represent a real assessment, certification or statement of conformity for any product.
Engineering path
From baseline to a verifiable remediation target
The Pack does not stop at the finding: it defines the intended technical transformation and the criterion used to verify the intervention on the next release.
Initial state
No SBOM, or an SBOM detached from the build
Technical intervention
Pipeline generation, normalization and dependency checks
Verification target
A versioned machine-readable inventory tied to the release
Initial state
Partial update flow with unproven recovery
Technical intervention
Signing, version policy, health checks, rollback and fault injection
Verification target
A repeatable update path with verifiable outcomes and recovery
Initial state
UART/JTAG access without an explicit policy
Technical intervention
Review production/service modes and harden technical access
Verification target
Interfaces disabled or governed by a technical procedure
Initial state
Services and ports without a reliable inventory
Technical intervention
Runtime mapping of privileges, certificates, firewall and configuration
Verification target
Reduced, justified exposed surface tied to the configuration
Initial state
No formal vulnerability-handling process
Technical intervention
Ownership, intake, triage, affected versions and fix workflow
Verification target
Vulnerabilities traceable from the component to the corrective release
A “verified” status is assigned only after implementation, retesting and collection of the evidence associated with the new release.
Practical engagement
How a real assessment starts
Work starts from the minimum useful material and an observable perimeter. Complete documentation is not a prerequisite: initial gaps are part of the baseline.
What the product team provides
The exact set depends on the product and can be shared in stages.
- Versions and variants to assess
- Available repositories, exports or binaries
- Builds, manifests, schematics, manuals and configuration
- Hardware or access to a test environment when required
Boundaries and criteria before analysis
Intended use, included components, interfaces, dependencies, reference release, constraints and assumptions are agreed first.
- An identified baseline before testing
- Access limited to what is necessary
- Priorities agreed with the technical team
- Explicit exclusions where applicable
Controlled handling of technical material
The NDA, transfer channel, access method and retention are defined before material is shared.
- Private repositories, targeted exports or local analysis as agreed
- Named, revocable access where available
- No publication or reuse without written authorization
- Agreed return or deletion of material at closure
Indicative planning: for one product with a focused perimeter, the initial baseline typically takes 1–3 weeks from access to useful material. Actual timing and phases depend on variants, artifact quality, hardware and interface count and are confirmed after scoping.
Qualification
Is this the right starting point for your product?
The assessment is intended for teams that need to turn an existing product into a technical perimeter that can be understood, traced and improved.
It is a good fit if
- You have a device, gateway, firmware or software product with digital elements intended for the EU market.
- The product and code exist, but the SBOM, update path, exposed surface or vulnerability handling are incomplete.
- You need to understand what must change and be able to implement work on firmware, software or backend systems.
- The team can identify at least one version and make a minimum set of technical material available.
It does not replace
- A notified body, certification, CE marking or declaration of conformity.
- Legal advice or regulatory product classification on its own.
- A document asserting compliance without product access and verifiable technical evidence.
- The manufacturer’s responsibility for conformity decisions and placing the product on the market.
Product qualification
Let us scope your Technical Evidence Pack
Share the product, baseline and material currently available. This is enough to understand whether the Pack fits, which parts to include and what is needed for a reliable scope.
Related guides and pages
The service page for applying the process to existing firmware, software or connected products.
Images, networking, UI, diagnostics, updates and maintenance for product gateways.
Telemetry, inventory, dashboards and lifecycle architecture for connected devices.
Signing, rollback, recovery and release diagnostics for field devices.
Context on firmware, SBOMs, updates and product lifecycle.
Official references used for the technical scope
The reference case uses primary EU sources to frame the technical evidence. Scope, product classification and conformity decisions remain the manufacturer’s responsibility.
Regulation (EU) 2024/2847
Official Cyber Resilience Act text, including essential requirements and technical-documentation content.
European Commission · Cyber Resilience Act
Institutional page covering application, obligations and regulatory milestones.
European Commission · Guidance C(2026) 5252
Non-binding guidance published on 27 July 2026 to support CRA implementation.
Frequently asked questions
Can I compare IG-200 with my product?
Yes. IG-200 combines elements common to gateways, IoT devices, connected machinery and embedded products. The Technical Evidence Pack is then adapted to the customer’s actual hardware revisions, firmware releases, interfaces, dependencies and processes.
Does the Technical Evidence Pack certify CRA compliance?
No. It provides technical analysis and evidence useful to the manufacturer’s process, but it is not a certification, CE marking, declaration of conformity or legal opinion.
Can you apply the same process to a product already in the field?
Yes. Work can start from repositories, builds, binaries, schematics, logs, manuals, system images and available hardware, after defining boundaries and constraints.
Can you correct the issues found?
Yes. Where included in the agreed scope, we can work on firmware, bootloader, gateway, backend, dashboard, builds, logging, updates and technical documentation.
How long does an initial baseline take?
For one product with a focused perimeter, it typically takes 1–3 weeks from access to useful material. The actual estimate depends on versions, variants, artifact quality, hardware availability and the number of interfaces.
How do you handle repositories, firmware and confidential material?
Before transfer, we define the NDA, access, sharing channel, retention and closure method. Private repositories, targeted exports or local analysis can be used according to the agreed scope; material is not published or reused without written authorization.