NIS2 already in force — German transposition under way

10 years building devices. Now with a focus on security.

I check the software that runs directly on your devices, make connected devices secure and protect your machines and plants — from someone who has built such devices for years.

Book a 30-min intro call

Unsure whether NIS2 applies to you?Start the self-check — 4 questions, 5 min

Does any of this sound familiar?

Situations we see all the time with machine builders, connected industry, medical technology and energy utilities. If your internet connection has never been checked either, take a look at Backend Security Audit — API, cloud & secure code as well:

Device software never reviewedYour devices are on the network, but nobody has ever checked the software on them for weaknesses.

NIS2 — and nobody knows where to startThe rules already apply and the German transposition is under way — but nobody inside your company looks after the security of your machines and plants.

Updates without an authenticity checkWhen device updates are installed remotely without checking that they really come from you, that's an open door.

Start-up protection off & unknown old codeThe devices could protect themselves against tampered software at start-up, but nobody has set that up. The last developer is gone, the software runs, but nobody knows what's inside anymore.

How the check of your device software works

Four steps, aligned with the recognised industry standard IEC 62443-4-1 and proven review practice. A device can be attacked in many places: at start-up, through the maintenance interface or through the update path. And unlike a website, a mistake on the device cannot simply be re-deployed in a second.

1. Define the scope & read out the softwareFirst we look at which components, start-up programs and operating systems are inside the device and where it can be reached from the outside or through a maintenance port. We clarify what kind of attack we protect against (remote, with the device in hand, via suppliers). For existing devices I read the software directly off the chip and work out what it is made of. For new projects I work directly from the source code.

2. Think through the threatsWe work through, step by step, how someone could attack the device — including tricks that only exist for devices: getting at secret data through side channels, rolling back to an old (insecure) update, or throwing the device off track with targeted electrical glitches. We clearly separate what is highly sensitive (secret keys) from ordinary operating data (settings, measurements).

3. Check the software — at rest and while runningI read the program code at the critical points (for example how it handles inputs and memory) and test the interfaces of the running device by deliberately feeding them unusual data. On top of that I check the update path and the start-up protection for gaps — on real hardware where it makes sense.

4. Report & fixEvery weakness found gets a severity rating, a clear description on exactly your device version, the possible consequences and a concrete way to fix it. On request I fix the issues myself — from setting up start-up protection to rebuilding the update path — and then check again afterwards.

Packages

Recommended entry point

NIS2 Readiness AuditWe look at where you stand today with the security of your machines and connected devices, and you get a clear plan with to-dos. Where are you today, what has to happen by October 2026? My approach and examples are in the overview of security projects.

1.Stocktaking: where are you today?

2.Risk assessment: what are the real threats?

3.Action plan: what must happen by October 2026?

4.Optional: implementation of the measures

Timeline: 1–2 weeks€3,000–5,000

Firmware Security AuditI check the software on your devices and think through the possible attacks. Find weaknesses before anyone else does.

Timeline: 1–3 weeks€5,000–12,000

Secure Boot & OTA HardeningI set up a secure update path and make sure devices only accept genuine, unaltered updates.

Timeline: Project-basedon request

IoT Architecture ReviewI review how your connected devices talk to each other and to the central system, and how access and keys are managed — from start to finish.

Timeline: 1–2 weekson request

Standards & rules

Different industries and device types are governed by different rules. I bring the relevant ones together so that both the technical implementation and the paperwork survive an official audit.

Secure start-up & a protected area in the chipAt start-up the device checks that its software is genuine and unchanged, and it prevents an old, insecure version from being put back. A specially protected area inside the chip (TrustZone on ARM Cortex-M/-A) keeps secret keys and safety-critical processes strictly apart from the rest of the program.

NIS2 for machines & plants and IEC 62443Two recognised industry standards define how devices are developed securely (IEC 62443-4-1) and what requirements the individual components must meet (IEC 62443-4-2, Security Levels 1–4). As a side effect, this produces exactly the documentation a NIS2 review asks for.

Cyber Resilience Act & UN R155/R156The Cyber Resilience Act (CRA) applies from September 2026: if a weakness is actively exploited, it must be reported within 24 hours. It also requires a complete list of all software components used (SBOM) and a fixed process for handling security gaps (PSIRT). In the automotive world, two UN rules are added — R155 for secure vehicle design and R156 for orderly software updates — already mandatory for type approvals.

Real-world example: amperetta hybrid drivetrain

Control software for a hybrid drive in sport boatsUsed out on the water, with many devices spread across a whole fleet, high demands on the split-second control of both the electric and the combustion engine, and control logic that has to react safely in an emergency. A mistake in the software has immediate, real consequences out on the boat.My contribution: I developed the control software and safely combined both drives into a single, shared control system. The focus was on the remote update path and the protection at start-up — the software has to be verifiably genuine, and a failed update must never push the fleet into an unsafe state.Outcome: a fully automated process that checks every new piece of software itself before it ships and only lets genuine, rollback-protected updates onto the devices. This process is still the blueprint I use to judge update paths in later audits.

What you can count on

10+ years building devicesBuilt, tested and shipped myself

Hardware + softwareCertified electrical automation technician

An attacker's mindsetHTB CBBH & CPTS candidate

Check + fixImplement the solution myself, not just report

FAQ — Embedded Security Audit

What is a security check for device software, and how long does it take?

Do connected devices have to meet the NIS2 rules?

What's the difference between checking the server systems and checking the device software?

How do you check whether the remote update path is secure?

We check, among other things: Is the start-up program genuine and protected? Does the device itself verify that an update really comes from you? How are the secret keys managed and replaced when needed? Is a rollback to an old, insecure version prevented? Is the transfer encrypted, and what happens if an update is interrupted? Common findings: no authenticity check, keys stored unprotected, no protection against rollbacks.

Which device types do you support?

How do you deal with pre-set default passwords on existing device fleets?

First a stocktaking: which devices carry which access data, and which accounts can be reached from outside? Then step by step: a remote update that forces the passwords to be changed, monitoring of the remaining devices, and the right documentation for the reporting obligations (NIS2/CRA). If a remote update isn't possible, we plan the replacement on site and shield the devices within the network as a stop-gap.

How secure are your cloud and your interfaces?

Your servers and online services are just as exposed as the software on your devices. Securing interfaces and the cloud, plus code reviews — all from one hand.

Backend Security Audit — API, cloud & secure code

Ready for a check of your device software or a NIS2 review?

30-minute intro call — free, no obligation, directly with the person who would carry out the check. Want to get to know my background first?

Book a 30-min intro call