EU CRA and IEC 62443 compliance: what nobody tells you (until costs go off the rails)

From what we’ve seen across dozens of projects, EU CRA compliance and overall cybersecurity improvement efforts often begin with the right intentions but can drift into trouble along the way. The toughest issues rarely show up on a checklist. Instead, they surface in legacy systems, scattered and outdated documentation, unclear responsibilities, and the challenge of getting all the right people and suppliers aligned.

Here’s what tends to come up repeatedly with industrial manufacturers:

• Legacy platforms not designed for security – documentation that’s patchy at best.
• Cybersecurity compliance requirements and feature discussions that turn into internal debates between R&D, IT, product, and management.
• Suppliers and partners say their bits are “covered,” but gaps multiply when you try to connect the dots.
• There’s plenty of technically excellent cybersecurity advice out there; but credible proof of what works for industrial devices under real-world conditions is much harder to find.

Insights from the field

A number of manufacturers have already started their CRA gap analyses, certified their operations for ISO 27001, and have a working knowledge of IEC 62443. The challenge is to understand what really works for their product in a business context, because this is where decisions become complicated:

• Architectural questions sit at the integration and firmware level, especially when your product is part platform, part client customization, and you still carry the core responsibility.
• Multiple generations of products create risk. New builds can fit with modern cybersecurity compliance requirements by design; years-old platforms force you to weigh what’s necessary and what’s practical to change.
• Flagship products that are settled in the field and generating good business cannot be tied up for major rework. At the same time, you cannot afford to ignore potential vulnerabilities, lose track of who owns which fixes, or fall behind competitors that require official compliance with an IEC 62443 standard or EU CRA requirements.

Even organizations with strong internal processes often need focused, external help to close the last gaps, align decisions, and keep the project moving.

Where most compliance efforts fall short

• Audit readiness depends on hands-on know-how. You need someone who understands your systems in detail. External advice is only as useful as your team’s ability to connect it to what’s running in production.
• Evidence matters more than theory. Every compliance requirement needs to tie back to real features or test cases, so that when you really need to trace back to the source of an issue you have tools to do it efficiently.
• Flexible controls are critical. Adding new security controls might look good on paper, but if it slows down your operations or causes other frictions in practice, you gain nothing.
• Traceability is non-negotiable. Documentation needs to reflect actual processes and changes, not paperwork patched up at the last minute.

What actually keeps projects on track

• Get all technical and business leads together early. R&D, IT, field support, suppliers – get aligned at the very start and clarify responsibilities before problems surface.
• Test for failure, not just for show. Have one of your toughest engineers take an auditor’s approach and challenge everything. Catching weaknesses early lets you fix them before they become a crisis.
• Push back on anything that doesn’t fit reality. Not every security control or update makes sense for active flagship products. Mainly, the answer comes from cybersecurity risk analysis, not the security features we would like to implement initially.
• Build documentation as you go. Capture traceability and evidence through every step. Trying to recreate a paper trail at the end leads to wasted effort and provides a false impression that the documentation is up to date.

What hands-on support really looks like

On a recent project with a manufacturer supporting a range of connected products, the basics were already in place: internal policies and established processes. The tougher work was sorting out which decisions belonged to the platform team and which risks needed to be managed by customers building their own applications on top.

We worked shoulder to shoulder with their engineers on gap analysis and cybersecurity risk assessment. We drew clear boundaries, prioritized which gaps put them at cybersecurity risk, and put together documentation and software fixes that matched reality.

Within a few months, the team had a prioritized roadmap, audit-ready evidence for the in-scope industrial drive platform and its configuration tooling, and a clear split of responsibilities between platform and customer, so certification and ongoing sales could continue without blocking the wider product portfolio.

Most of the real conversations weren’t about the standard itself – they were about what’s “enough” and feasible at the same time – what’s realistic for products with limited resources and conflicting use cases, and what keeps business moving without chasing compliance for compliance’s sake.

That’s what field-level support is all about: giving clear input, driving decisions, and making sure work gets delivered so you aren’t betting everything on cutting‑edge cybersecurity controls that balloon the development cost, make technicians’ lives exponentially complex and in some cases may even contradict non-functional requirements of the device – that’s the case especially with devices meant to operate in industrial environments.

What our compliance analysis actually includes

When we talk about EU CRA and IEC 62443 compliance analysis, we mean a set of practical activities that can be used independently or combined, depending on the state of your products and organization: · Gap analysis – Mapping your products, architecture, and development practices against EU CRA and IEC 62443 requirements, to establish where you stand and which gaps matter.

• Cybersecurity risk assessment – prioritizing those gaps based on realistic risk to the business and to end users, rather than treating all findings as equal checklist items.
• Documentation and traceability – establishing or repairing the link between requirements, design decisions, implementation, and test evidence, so auditors can clearly see what was done and why.
• Remediation planning – defining a realistic roadmap: what needs to be fixed now, what can wait, and what can be handled through documentation, compensating controls, or formal risk acceptance instead of costly rework.

Engagements are typically project-based (e.g. 2–4 months for a first gap analysis and roadmap), with the option to continue with focused support as you implement. We work on your side: in your docs, your repo where it makes sense, and in workshops with your R&D, IT, and product people – so the output is something your team can own and maintain.

How we fit with your existing setup

We do not replace your certification body or your internal quality and security teams. We complement them by helping you reach a state where gaps, priorities, evidence, and documentation are clear and defensible.

What we deliver – gap reports, risk assessments, traceability structures, and remediation plans – is structured so your own teams or your chosen certification partner can use it directly during audit and certification. Our role is to close the gap between knowing compliance is required and being able to demonstrate it clearly to an auditor.

What to bring when we start

You do not need a perfect dossier on day one. To make the initial sessions productive, bring whatever you already have: a product or portfolio list showing what is in scope for CRA or IEC 62443, a high-level system or architecture overview, and any existing security, quality, or process documentation.

We work from that baseline and identify what is missing or needs clarification, so time in the first workshops is spent on real gaps rather than on assembling paperwork.

Let’s talk – and make progress from day one

If you’re wrestling with responsibility boundaries, questions about long-lived flagship products, or seeing cybersecurity risk and compliance costs balloon without results, let’s talk.

Bring your working docs, technical headaches, or open questions to Embedded World 2026. We’ll talk them through and help you identify concrete next steps – not just theory.

---

About the author

Terry London is a Product Manager and Partner at Proekspert, working with industrial manufacturers on EU CRA and IEC 62443 compliance, cybersecurity risk assessment, and long-lived product platforms.

Meet Terry, the author of this article and a CRA specialist, at Embedded World 2026.

Hall 5, Booth 5-189b · March 10–12 · Nuremberg
Questions or ticket requests: info@proekspert.com

Schedule a focused 15-minute discussion →

About Proekspert

Proekspert is a skilled software development company with over 30 years of experience. We have encountered many diverse approaches to equipment, software engineering, and cybersecurity. Our expertise covers embedded software, device-cloud integrations, technician apps, and portals.