Lessons from early CRA pilots on testing and documentation
Early CRA pilots show why compliance isn’t just a security exercise. It’s about proving cyber resilience in real products, building the evidence to demonstrate it, and helping teams make sense of new obligations, especially where resources are tight.
With the EU Cyber Resilience Act (CRA) now in force and key obligations phased in over the next few years, many organisations are asking the same question: “How do we know we’re ready?”
The CRA sets baseline cyber security requirements for products with digital elements (hardware and software), sold into the EU. It also introduces ongoing expectations around vulnerability handling and incident reporting, meaning compliance is not a one-off certification moment. It’s a lifecycle discipline.
In our pilot assessments we focused on two practical things: (1) validating CRA-aligned security tooling against real devices and (2) validating the CRA documentation and checklists by supporting a documentation self-assessment. The pilots were designed to be collaborative. They were to help participating organisations get an early view of readiness, while feeding real-world learnings back into the tooling and guidance.
Testing cyber resilience in the messy real world
CRA expectations usually land on the product: has security been built in from the start? Can teams show how they handle software components and vulnerabilities over time? Can the product withstand realistic abuse, malformed inputs, unexpected traffic and protocol edge-cases without failing in unsafe ways? In connected products, that often means testing the software and the interfaces attackers would actually target – Bluetooth, Wi‑Fi, cellular connectivity and exposed services.
One technique we used in pilots is protocol “fuzzing”: deliberately sending unexpected, invalid, or high-volume messages to see whether a product continues to behave safely and predictably. It’s different from “breaking in” to gain access. It’s about resilience under stress and failure modes. The kind of thing that can turn a minor bug into a real-world customer incident.
Example 1:
Smart access product – resilience failures are user-impacting failures
In one pilot with a smart access manufacturer, fuzzing tests revealed a scenario where unexpected traffic could lead to the product becoming unresponsive. That matters because resilience issues aren’t abstract: a smart access device that disconnects or becomes unresponsive can translate into real customer lock-outs, support costs, and reputational risk. The upside of finding issues early is that remediation can be planned on the manufacturer’s timeline, before regulatory deadlines and before widespread customer exposure.
Example 2:
Smart heating – strong results still need evidence
Another pilot focused on a connected smart home provider. The technical testing outcomes were strong, with no major issues raised by the pilot tooling. But that doesn’t mean the work is ‘done’. CRA readiness also depends on being able to repeat the checks, keep them current as the product evolves and retain evidence that shows what was tested, when and how issues are handled over time.
Example 3:
The “where do we start?” problem (and why checklists help)
In one SME pilot, the biggest value was structured guidance on how to begin the documentation self-assessment. The organisation had capable engineers, but limited specialist capacity to interpret requirements, decide what evidence was ‘good enough’, and spot gaps early. A checklist-driven approach helped turn an overwhelming requirement set into a manageable sequence of actions: gather what exists, map it to CRA expectations, identify gaps, and iterate.
The key takeaway from the pilots is that tooling and documentation are inseparable. Tooling helps uncover real technical risks; documentation and process determine whether those risks are handled consistently, transparently and at the speed CRA will expect.
Why documentation matters: proving you did the right things (and can keep doing them)
For many teams, the hardest part of CRA isn’t running a security test. It’s building and maintaining the documentation and processes that sit behind it. Documentation is how you demonstrate that security-by-design was applied, that vulnerabilities are handled consistently, and that responsibilities are clear across engineering, product, legal and support.
In pilots, we repeatedly saw that documentation work can feel like a ‘minefield’, especially for SMEs without dedicated legal or compliance departments. Requirements cut across multiple disciplines: product architecture, secure development practices, update support periods, vulnerability intake/triage, customer communications, and incident reporting. Getting this right isn’t just about writing process documents. It’s about aligning how the organisation actually operates.
Why Resillion is involved: turning CRA intent into something teams can actually use
CRA raises the bar, but many organisations, especially smaller manufacturers, need practical ways to interpret requirements and apply them to real products. That’s the goal of CRACY (“CRA Compliance made easY”): guidance and tooling that support CRA-style self-assessments and help teams move from uncertainty to a concrete plan.
Resillion is involved because of our experience in product security testing and assurance, and because we are leading the CRACY work package focused on the tooling. In practice, that means we’re not only building and validating CRA-aligned test approaches, but also coordinating how tooling contributions fit together, and ensuring lessons from pilots translate into improvements that benefit the wider community.
What’s next
Across the pilots, three themes stood out:
If you’re building or selling products with digital elements into the EU and want an early view of CRA readiness, the best time to start is before deadlines force rushed decisions. We’ve anonymised the pilot examples in this post to keep participating organisations confidential while sharing the practical lessons that are broadly applicable.
LIVE WEBINAR
Supercharging AI assurance with Test Data Automation
Is your test data ready for scalable AI assurance under NIS2?
Get in touch
Providing solutions in a unified, structured approach across all critical domains to enable end-to-end quality – Because we’re the only ones who can.
