Acecode Ky

When a device needs to be understood below the surface.

Acecode combines firmware analysis, board-level work, measurement and reporting into evidence that engineering, management and compliance can actually use.

Acecode electronics lab and embedded hardware work

Practical assessment, not security theatre

HW/FW Security Assessment shows what a connected embedded product actually exposes: debug interfaces, boot behaviour, firmware and update chain, device identity, component risks and evidence that can be documented.

The work does not stop at a scanner-style output. It produces observations, photos, measurement and test diary entries, finding severity, remediation guidance and, where useful, a CRA-oriented traceability view.

Core service

Acecode fits situations where a manufacturer wants an experienced external technical view before customer due diligence, certification discussions, CRA preparation or the next product security remediation cycle.

Three ways to help

  • Extended hardware pentest / HW/FW Security Assessment: scoped, evidence-based review of the device-level attack surface, firmware, debug interfaces and CRA evidence matrix.
  • Embedded SW/HW Consulting: experienced help for firmware, Embedded Linux, board bring-up, legacy systems, diagnostics and difficult HW/SW boundaries.
  • Electronics Diagnostics / Repair: lab-based PCB fault analysis, repair assessment and root-cause investigation for valuable, unusual or industrial electronics.

Why now

Customers, partners and assessors increasingly ask for concrete evidence of how device firmware, service interfaces and update paths are controlled. A strong answer comes from lab work, not just a promise.

If a manufacturer enters a CRA, customer or NB discussion without device-level evidence, gaps are often discovered at the most expensive and schedule-sensitive moment. Acecode's idea is to do the practical HW/FW work first: identify the relevant risks, document them and create a pre-NB style evidence pack that supports remediation and later discussions.

Acecode does not certify the product. It helps create the material that allows the manufacturer to move to the next step with a much stronger technical basis.

How engagements usually start

  • A short technical review call to understand the product and evidence need.
  • A scoped assessment, consulting or diagnostics plan.
  • A deliverable that engineering, management and compliance stakeholders can actually use.
Extended hardware pentest

Debug paths, firmware, update chain, CRA evidence matrix and remediation planning in one technical package.

Senior Embedded SW/HW

30+ years of embedded experience from board bring-up to legacy modernization and difficult HW/SW boundaries.

Electronics Diagnostics / Repair

A capable lab, measurement equipment and repair-oriented analysis for valuable or unusual electronics.

Why Acecode now

Make the expensive assessment path easier before it starts.

If the first real device-level testing happens only during a customer, partner or NB discussion, surprises quickly become schedule and cost problems. Acecode performs the scoped practical HW/FW work first and turns it into a clear evidence package.

01

Manufacturer evidence first

Under the CRA path the manufacturer needs risk assessment, technical documentation and practical controls before demanding reviews.

02

An NB assesses, it does not build evidence

A Notified Body may be needed for certain product classes, but its role is to assess evidence. Device-level gaps are cheaper to find before that table.

03

Keep cost under control

A scoped HW/FW assessment creates a pre-NB evidence pack: observations, photos, test diary and remediation path without starting a heavy certification project.

What the assessment covers

A short path from technical uncertainty to decision-grade evidence.

The work connects board-level observations, firmware paths, measurements and reporting so the product team can see what to fix first.

ScopeChain of custodyBoard inspectionDebug & service pathsFirmware reviewRemediation path

CRA information pack

What does the CRA mean at hardware and firmware level?

A short practical starting point for device manufacturers. More CRA/HW notes are coming, but these already frame where evidence is created.

The CRA is not only software

PCB, firmware, debug interfaces, boot chain, update mechanism, radio and component choices all affect what the manufacturer must be able to prove.

Product class shapes the route

Many products can use manufacturer self-assessment. Some important and critical classes require stronger assessment or a Notified Body route.

Pre-NB evidence pack

Acecode does not certify the product. It creates technical evidence so the manufacturer can fix gaps and discuss facts with customers, partners or an NB.

Reporting starts earlier

CRA vulnerability and severe incident reporting obligations start before the main obligations, so the device-level process should be built early.

11 Jun 2026NB chapter applies11 Sep 2026reporting obligations11 Dec 2027main obligations
From earlier LinkedIn notes

Condensed points from earlier Acecode CRA/HW post drafts. More practical notes are coming, especially on what the CRA means at hardware and firmware level.

LinkedIn note: an NB does not create evidence

A Notified Body assesses evidence. Before that route, the manufacturer should already have risk-based HW/FW architecture evidence, secure boot and OTA evidence, debug-port status, firmware extraction results and traceability to CRA Annex I.

LinkedIn note: what a pre-NB evidence pack contains

Not a certificate, but a technical proof base: product classification rationale, device threat model, PCB and component review, debug-port assessment, firmware/OTA path, radio exposure, SBOM/CVE view and remediation plan before NB submission.

LinkedIn note: the standards gap is also a hardware problem

When harmonised standards are not ready or not fully applied, manufacturers need direct Annex I evidence. For hardware products that means tested device evidence, not only process documentation.

LinkedIn note: vulnerability handling reaches the device

The prEN 40000-1-3 angle brings SBOM, update delivery, monitoring and disclosure process together. A HW/FW assessment ties those controls to the real device: firmware in use, components present and fixes needed.

Background: EU CRA summary and conformity assessment guidance. CRA summary Conformity assessment

Request a sample report

Get the sanitized report structure and see how evidence, findings and remediation advice are presented.