Security Audits
A review of your architecture and implementation against radio and embedded attacks, including the security requirements of the Cyber Resilience Act (CRA) and NIS2, with fixes your team can fit into the release you are already planning.
- A product is heading for release or certification
- You need to meet the Cyber Resilience Act (CRA) or NIS2
- You want to find problems before your customers do
- You need fixes you can plan into your schedule
- A certifier will ask for evidence
How it runs
We keep you informed during the work. Serious findings are reported the same day, not held back for the report.
Scoping
What is being built, what it has to pass, and which parts are in scope. We agree on what we need from your side.
Review
Architecture and threat model first, then the implementation: firmware, boot chain, radio provisioning and hardware.
Findings
Each issue with its impact, the standard it relates to, and a fix your team can include in the planned release.
Retest
A follow-up check once the fixes are in, with evidence a certifier will accept.
Deliverables
A report your engineers can act on, a summary your management can read, and everything needed to reproduce each finding.
- Audit report
- Findings mapped to the attack surface and the relevant standards
- Remediation plan
- Prioritised, with effort estimates your team can schedule
- Certifier evidence
- Documentation packaged for the certification body
- Design guidance
- What to change in the next revision
- Retest report
- Confirmation of what was fixed
| Target | What that involves |
|---|---|
| Radio architecture | Protocols, trust boundaries, key handling, provisioning and update paths |
| Firmware and bootchain | Secure boot, signing, rollback protection, secrets at rest |
| Hardware | Debug ports, external interfaces, tamper and fault-injection resistance |
| Provisioning | How devices get their identities and keys in the factory and field |
| CRA | Security requirements for products with digital elements: attack surface, secure updates, vulnerability handling |
| NIS2 | Technical security measures and their testing, for essential and important entities |
| Other requirements | Radio and sector-specific security standards |
Frequently asked questions
Can you help with NIS2 or the CRA?
Yes. Penthertz assesses your products and systems against the security requirements behind NIS2 and the Cyber Resilience Act, then gives you the technical evidence and a prioritised remediation plan. We focus on the parts others skip, the radio links and the electronics inside your devices, and test them the way an assessor or an attacker would. We work alongside your compliance or legal team, who own the regulatory mapping, while we provide the hands-on testing and proof. The result is something you can show auditors, not just a filled-in checklist.
Do you certify products?
No. Penthertz is not a certification body, and we are careful not to claim otherwise, because the same organisation cannot credibly both test and certify. What we do is produce the evidence and the fixes a certifier or notified body will expect: a clear assessment of your product's radio and hardware security, reproducible findings, and concrete remediation. You, or your certification body, then use that work in the formal assessment. Keeping the roles separate also means our testing stays genuinely independent of the certification outcome.
How early can you start?
As soon as you have an architecture diagram. Penthertz would rather look at a design than wait for a finished product, because the earlier a flaw is found the cheaper it is to fix, and a change on paper costs far less than a recall. We can review an architecture, then test prototypes, then the final hardware, so security is checked at each stage rather than bolted on at the end. If you are already in production we still start wherever you are and work back from there.
Talk to us about your project
We scope the work in a first call, then send a fixed-price proposal. We can put a mutual NDA in place before discussing details.