Imagine a mid-sized smart device manufacturer gearing up to launch in Europe. New EU rules demand that connected products meet rigorous cybersecurity requirements, but the company actually doesn’t have an advanced security lab or a team of compliance auditors on staff. Lower-risk gadgets can sometimes be self-assessed by the manufacturer, but anything deemed higher-risk (like Class II under the upcoming Cyber Resilience Act) must be tested or audited by an independent lab. Building an in-house ISO 17025-accredited lab isn’t realistic for most vendors. The result: Looming compliance crunch of how can manufacturers meet the Radio Equipment Directive delegated act (RED-DA) and Cyber Resilience Act (CRA) mandates without running their own lab?

Why This Matters Now

In recent years, the EU has raised the bar for product cybersecurity. The Radio Equipment Directive’s delegated regulation (EU) 2022/30 activated new essential requirements (RED Articles 3.3 (d), (e), (f)) - covering network protection, data privacy, and fraud prevention - for any wireless or IoT device that connects to the Internet. These provisions became mandatory by August 2024, meaning many radio-connected consumer products must now include cybersecurity safeguards or risk being pulled from the market. In parallel, the Cyber Resilience Act (CRA) was adopted at the end of 2024 and will impose baseline security obligations on all “products with digital elements.” Its main requirements apply from late 2027, but critically, certain “important” or “critical” products (e.g., CRA Class II high-risk categories) will require third-party conformity assessment well before that date. In other words, if your smart gadget or software can significantly impact cybersecurity (think of network gear, intrusion detectors, payment devices, etc.), you cannot simply self-declare compliance - you’ll need an independent evaluation.

To comply, manufacturers have two broad paths: (1) Self-assessment (using internal testing or existing standards) for lower-risk products, or (2) Third-party assessment via an accredited lab or Notified Body for higher-risk products. The challenge is that most companies are not equipped to do the first option beyond basic measures, and the second option depends on external labs with limited capacity. The European Commission and standards organizations are developing technical standards (like ETSI EN 303 645 and the new EN 18031 series) to guide compliance testing. But even with standards in hand, the reality is that few manufacturers can afford to build an in-house ISO 17025 lab to fully test their products against these requirements. It’s simply not cost-effective or practical to recreate an accredited conformity assessment body within every device company. This is why a majority of vendors, especially small and mid-sized ones, will be working with external security labs and Notified Bodies as these regulations take effect.

The Real Bottlenecks Vendors Face

Figure 1

How prepared is your team for third-party assessment? Many vendors aren’t fully ready. To self-diagnose your readiness, consider the checklist in Figure 2 below - it highlights key questions any manufacturer should answer before sending a product to an external lab.

Figure 2

The Practical Path Forward

The good news is that manufacturers don’t have to choose between doing nothing and building their own certified lab. A practical middle path is emerging: treat the third-party assessment as a finish line, not the entire race. In practice, this means front-loading your compliance effort into a structured in-house readiness phase, so that when you eventually go to an external lab, it’s a relatively routine verification step rather than an open-ended fishing expedition.

Concretely, vendors should approach RED/CRA compliance in two stages:

1. Structured Readiness (Pre-Assessment): Long before you book a lab, perform an internal conformity check against the relevant requirements. Map your product against each security control mandated by RED Article 3.3 and CRA Annex I. Identify gaps in both implementation and evidence: do you have secure boot and encryption in place (and tests to prove it)? Are all known vulnerabilities patched or documented? Is there a complete risk assessment and secure development lifecycle record? This stage often involves using existing standards and tools – for instance, testing your device against ETSI EN 303 645 best practices, or following the upcoming EN 18031-x test cases for network resilience and privacy. By doing so, you dramatically reduce unknowns. Think of it as pre-compliance testing for cybersecurity: it’s cheaper to fail internally and fix issues now than to fail in a costly lab later. Use checklists, automated scanners, or even third-party consultants in advisory roles to validate that your product would likely pass a formal evaluation. Essentially, you want to reach a point where you expect to pass the audit because you’ve practically done it yourself already.
2. Targeted Third-Party Assessment (Finish Line): With a clean package of evidence and a hardened product, you then engage an accredited lab or Notified Body for the official conformity assessment. Since you’ve scoped the work carefully, you can shrink the lab’s scope to only the necessary validation tests. Instead of paying them to tell you what’s wrong, you’re asking them to confirm that everything is right. The third-party can focus on high-end verification (e.g., penetration testing or reviewing niche requirements) while trusting the comprehensive evidence you provide for the rest. By treating their certificate as a final seal of approval on work you’ve largely done, you regain control of the timeline. You’re also a much more attractive client for labs: because you come prepared, the assessment is straightforward, and they can complete it in less time (meaning they can fit you into their schedule more easily despite the capacity crunch). In short, readiness first translates to faster, smoother, and cheaper compliance in the end.

How CyberPass De-Risks RED/CRA Compliance for Vendors

This two-stage approach might sound great in theory, but how do you execute it efficiently? This is where a platform like CyberPass comes in. CyberPass is designed as a practical bridge between manufacturers and labs - enabling the structured readiness phase and streamlining the final hand-off. Here’s how it helps de-risk the process:

• Readiness Scoring & Gap Closure: CyberPass translates the sprawling RED/CRA requirements into an actionable checklist for your specific product. It automatically maps your device’s features to the applicable controls (e.g., encryption, authentication, secure update mechanisms) and scores your readiness. More importantly, it flags gaps - missing proofs or unmet controls - early. Rather than discovering during a lab test that you lack, say, a proper privacy notice or secure element certification, you’ll know upfront and can fix it. This scoring gives you a clear “to-do list” to reach compliance before any third-party is involved.
  
• Evidence Orchestration: An underrated challenge in compliance is simply managing all the evidence. CyberPass serves as a single source of truth for all your compliance artifacts - SBOMs, penetration test reports, risk assessment documents, architecture diagrams, encryption key management policies, and even those signed Statements of Conformity (SoCs) from component suppliers. Each item is version-controlled and tied to specific requirements. When you update the firmware or mitigate a vulnerability, you can attach the new test results or risk analysis directly. This orchestration ensures nothing falls through the cracks and that you’re always looking at the latest, approved evidence. When it’s time to involve a lab, you’re not scrambling through SharePoint folders or emails; everything is neatly packaged in one place.
  
• Smart Scoping for Labs: CyberPass can generate a test-ready package for the lab, including a structured Technical File and a suggested test plan. Essentially, it tells the lab, “Here is exactly what needs to be validated.” If you’ve already run a certified fuzz test or code audit internally, that evidence is highlighted - so the lab doesn’t waste hours re-doing it (unless required). By clearly delineating what has been done and what you’re asking the lab to do, you reduce redundant testing. Labs can then right-size their effort (and their quote), focusing on the few high-risk areas or any regulatory must-haves that require their stamp. The scope is clean, which reduces both cost and time.
  
• Lab Hand-Off & Workflow: Once third-party testing begins, CyberPass acts as the collaboration hub. You can give the external assessors access to the relevant evidence directly on the platform, under strict roles and permissions. Any findings or issues the lab raises can be logged and tracked to resolution, with a clear RACI matrix assigning who’s responsible to fix or clarify each point. For example, if the lab finds a vulnerability, your engineer gets an alert, patches it, and uploads a new test result; the lab is then notified to review the update. All communication stays within the platform, creating an audit trail that proves how each non-conformity was addressed. This structured workflow avoids the chaos of long email threads and ensures that when the lab is done, there are no loose ends.
  
• “Verified by Lab” Artifacts: CyberPass also supports a lightweight authenticity check on your evidences. With your permission, certain test results or documents can be tagged as “Verified by [Lab Name]” after a third-party review. For instance, if you have an in-house penetration test report, you might ask a lab to quickly review and endorse it in CyberPass. This isn’t a full certification, but it provides an extra layer of trust for stakeholders (even customers or regulators) that key security proofs have been independently verified. It helps build confidence without always needing a full-blown certification for every minor product update.

• Faster Cycles (Reuse and Iterate): Compliance is not a one-time event - products evolve, firmware updates roll out, new versions launch. CyberPass is built for reusability. Once a given artifact (say, a cryptography module validation or an SBOM for a common component) is approved, it can be applied across multiple product models or software versions. The platform tracks which parts of your compliance package remain valid and which need updating when something changes. This means the second time you go through compliance (for a product variant or a major update), the effort and lab involvement needed are much smaller. By capturing institutional knowledge and reusing evidence, you avoid starting from scratch each cycle. Ultimately, this speeds up innovation - you can implement new features or patch security issues and rapidly get an updated compliance sign-off because the groundwork is already laid.
  

In short, CyberPass helps you do the homework so that the final exam (the third-party assessment) is a formality. It tackles the coordination, cost, and capacity risks head-on: coordination is improved via a single source of truth and workflow; cost is reduced by eliminating duplicate lab work; capacity risk is mitigated by making your project easy to slot in (and by reducing the need for scarce lab hours per product).

What Good Looks Like: Before-and-After with Structured Readiness

To illustrate the impact, consider a before-and-after scenario of a vendor pursuing Class II CRA compliance:

Before. Acme IoT (a fictional IoT company) approached compliance in an ad-hoc way. Their engineers dumped various documents (architecture diagrams, some test results, a basic SBOM) into a shared drive and sent that to a lab, hoping for the best. The scope of testing was hazy - Acme figured the lab would “just handle it.” What followed were 10 weeks of uncertainty. The lab kept finding missing pieces: Where is your threat model? Please provide evidence of secure boot. Each email kicked off a frantic internal search. The lab’s time (and Acme’s money) was spent identifying basic gaps. Scheduling dragged on, and because the first test round uncovered issues, Acme had to book a second round weeks later. In total, it took ~12 weeks and 150% of the budget to (barely) achieve compliance. Market launch was delayed and unpredictable up until the end.

After CyberPass. Now consider Acme’s next product using the CyberPass-enabled approach. Months before involving a lab, Acme’s team uses CyberPass to conduct a thorough readiness check. They discover 3 missing controls (no formal privacy policy, an outdated open-source component with a known CVE, and incomplete encryption key management docs) and fix them in-house within weeks. CyberPass organizes all of Acme’s evidence - every requirement is backed by a document, test report, or rationale. When Acme engages a lab, they present a complete technical file and a focused test plan. The lab’s assessment is completed in 3 weeks with minimal findings. Acme addresses the few minor issues in-platform, the lab signs off, and that’s it : a clean pass. Because everything was defined and pre-validated, Acme was able to book a predictable test slot and hit their market launch on time. The total cost was 40% lower, and the team has confidence that next time will be even faster (since CyberPass retains the evidence for reuse). In summary, good looks like a defined scope, pre-validated evidence, and a low-drama third-party review, versus the chaos and uncertainty of the “dump it on the lab” approach.

Call to Action: For vendors navigating RED and CRA, the message is clear - you can comply without building your own lab, but you need to start early and get organized. Don’t wait until 2027 (or the eve of a RED deadline) to scramble for a lab slot. Begin your structured readiness now. If you’re unsure where to start, consider leveraging tools and expert guidance. Book a 30-minute RED/CRA readiness review with our CyberPass team (we’ll assess your current state and map out a game plan), or download our RED/CRA Readiness Checklist to self-assess your gaps. With the right preparation, you can turn regulatory compliance from a hurdle into a competitive advantage.

What to Do Monday (Practical Steps)

• Classify Your Products: Start by determining how the new rules apply to each of your products. Is your device in RED scope (does it have a radio transmitting/receiving)? Will it fall under CRA Class II (high-risk) or Class I? Knowing this will tell you whether you can self-assess or will need a Notified Body . If unsure, err on the side of assuming a third-party will be involved – it’s safer to prepare for it.
  
  
• Map Requirements Early: Obtain the relevant standards or baseline requirements (e.g., ETSI EN 303 645, draft EN 18031 series, or CRA Annex I) and map them to your product features. Create a spreadsheet or use a platform to list each requirement and record how your product meets it (or what is missing). Do this during design and development, not at the end. This living requirements traceability will save huge time later and ensures security is “baked in” from the start.
  
  
• Centralize Your Evidence: Gather all existing security documentation and artifacts into one repository. This includes design documents, architecture risk assessments, test results (penetration testing, code reviews, etc.), your SBOM, user manuals (security instructions), incident response plans – anything that might be needed to demonstrate compliance. Organize them by requirement area. If you don’t have a central compliance folder, create one now. This will highlight any obvious gaps (e.g., no pen-test done yet, or missing user security guidelines).
  
  
• Perform a Gap Analysis (Readiness Audit): Do an internal audit against the compliance checklist. If you have a security or QA team, have them play “Notified Body” and review your technical file as if you were submitting to an authority. Identify weaknesses: Are all high-risk vulnerabilities fixed or documented with a rationale? Do you have at least one test report or piece of evidence for each requirement? Where you find gaps, schedule the work (development or documentation tasks) to close them. This step might also involve basic pre-testing – for example, run open-source security scanning tools on your product, do a trial run of an update procedure, or have an external consultant do a quick audit. Better to find and fix issues now than later.
  
  
• Engage with Labs Proactively: Contact a few accredited labs or potential Notified Bodies early – even a year or more before you need formal certification. Discuss your product and ask about their scheduling and any pre-submission expectations. You might even consider a paid pre-assessment or consulting session with a lab to review your readiness package. This can give insight into how that specific lab likes to see information presented. Early engagement also tentatively reserves you a spot in their queue and puts you on their radar as a serious, prepared client.
  
  
• Leverage Automation and Tools: Consider using a compliance management tool (such as CyberPass, as discussed) or at least automated checkers for parts of the process. For instance, use vulnerability scanners to continuously monitor your SBOM for known flaws, or use document templates for the required policies (security maintenance plan, incident reporting procedure, etc.). Automation can alert you to new issues (e.g., a new CVE in a library) well before a third-party assessor would, enabling you to remediate in advance. It also reduces human error in assembling the huge volume of evidence.
  
  
• Rehearse the Handoff: Before you officially submit to a lab, do a dry run of packaging your compliance evidence. Prepare the draft Declaration of Conformity, fill out the lab’s intake forms, compile all test reports, and write an executive summary of your product’s security for the evaluator. This exercise often reveals last-minute gaps or areas where the narrative is unclear. It’s much better to refine these internally than under time pressure once the formal process starts. Essentially, be your own worst critic first - so that the real assessment feels easy.
  
  
• Stay Informed and Adapt: Make someone on your team responsible for monitoring RED/CRA developments - e.g., new standard releases, guidance from the EU Commission or ENISA, and industry best practices. Regulations evolve, and staying ahead of changes (like a new harmonized standard that could simplify your process) is key. For example, if a harmonized standard for CRA gets published in 2025, adopting it might let you self-declare compliance for certain products, saving you a third-party assessment. An informed team can pivot its strategy to leverage such opportunities.
  
  
• Invest in Security Culture: Finally, use this compliance exercise as a catalyst to build a stronger security culture in your organization. Train your developers on secure coding (to meet those Annex I requirements), establish routine security testing in your CI/CD pipeline, and maintain that single source of truth for security artifacts. Compliance is easier when it’s a natural outcome of good security practices, rather than a one-time scramble. The goal is not just to pass an audit, but to actually reduce your product’s risk and build customer trust. By integrating these practices into “business as usual,” you’ll find future regulations (or updates to CRA) much less intimidating.
  

End Notes

• [1] European Commission, Shaping Europe’s Digital Future – Cyber Resilience Act, last updated 6 March 2025 . (Official announcement that the CRA entered into force on 10 Dec 2024, with main obligations applying from 11 Dec 2027.)
  
• [2] Steven Farmer et al., “The EU’s Cyber Resilience Act: New Cybersecurity Requirements for Connected Products and Software,” Pillsbury Law (client alert, 2024). (Explains the CRA’s conformity assessment regime – Class I products can be self-assessed if standards are used; Class II “important” products or any without harmonized standards require third-party assessment.)
  
• [3] Green Mountain Electromagnetics, “Pre-Compliance CE Testing: How to Catch Problems Before the Final Test,” GME Blog, Mar. 13, 2025. (Highlights the pitfalls of skipping pre-compliance testing – products that fail final certification face costly re-tests and delays, and issues are easier/cheaper to fix early in development.)
  
• [4] Maven Prof. Services, “Why Preparing Your IVDR Technical Documentation Early is Crucial,” Maven Blog, 2023. (Though about medical devices, notes that submitting incomplete or outdated checklists/documentation leads to non-compliance and significant delays in conformity assessments – underscoring the importance of complete evidence for any regulated product.)
  
• [5] AssurX, “Update: EU Medical Device Regulation Deadlines Extended,” AssurX Blog, April 25, 2023. (Describes how a shortage of Notified Bodies under EU MDR caused severe certification backlogs; as of 2023, only 35 NBs were available, leading to timeline extensions. This is analogous to potential lab capacity issues for CRA.)