CRA Conformity: Lessons from ENISA's EUDI Wallet Scheme [2026]

On April 3, 2026, ENISA published draft v0.4.614 of the EU Digital Identity Wallet certification scheme: 110 pages, a public consultation closing April 30, and a webinar on April 8. This is the first cybersecurity certification scheme for ICT services ever drafted under the EU Cybersecurity Act. The EUCC already covers ICT products; this scheme breaks new ground by applying the same framework to services. It targets digital identity wallets, not products in general. But the evidence standards, supply chain obligations, and conformity infrastructure it establishes will shape how all EU cybersecurity certification works, including the schemes that will eventually govern CRA products. Here is what the scheme requires, where CRA is explicitly referenced, and what product manufacturers should track.

Why a Wallet Scheme Matters to Product Manufacturers

The EUDI Wallet scheme and the CRA operate on different legal objects. CRA governs products with digital elements placed on the EU market. The wallet scheme governs a specific type of service: the EUDI Wallet Solution. They are not the same regulation.

But they share legal plumbing.

Article 24 and Article 27 of the CRA both reference EU cybersecurity certification schemes under the Cybersecurity Act as an alternative conformity path. A product covered by an applicable CSA scheme can use certification under that scheme to demonstrate conformity with the corresponding CRA essential requirements. No such scheme covering CRA products exists yet. The EUDI Wallet scheme is the first one drafted, and the choices ENISA makes here, on evidence formats, supply chain requirements, and evaluation methodology, will carry forward.

The scheme draws a clear jurisdictional line on page 9. The text is direct: CRA "does not apply directly to EUDI Wallets as they are certified in the context of the present scheme, since they are certified as ICT services, not ICT products." For most EUDIW participants, CRA is not a parallel obligation. The scheme borrowed from CRA's methodology selectively, but that borrowing doesn't extend the regulation's scope.

The exception is mobile. When the wallet instance is a mobile application placed on the market by a commercial entity, CRA applies to that application as a product with digital elements. For companies distributing a mobile wallet app commercially, two regimes apply simultaneously. CRA covers pre-market conformity and post-market vulnerability management obligations on the product. The wallet scheme covers the continuous service certification. They stack, but only in this specific scenario. An organization providing a wallet solution purely as an ICT service has no CRA obligation through this scheme.

The shared framework includes the CSA and the European Common Criteria-based evaluation framework (ECCF), CEN TS 18072 for wallet service requirements, and the EUCC (EU Common Criteria-based cybersecurity certification scheme) as the compositional base for hardware and platform components. None of that infrastructure was built for wallets alone. It's the skeleton that future CRA-adjacent schemes will use.

One further boundary: the scheme states that EUDIW certificates "will not be suitable for presumption of conformity" under the CRA (p.9). Even for mobile wallet apps where CRA does apply, the EUDIW certificate does not satisfy CRA conformity. The two compliance tracks are separate and must each be completed independently.

Mobile wallet distributors: two independent compliance tracks. If you are a commercial entity placing a mobile wallet app on the EU market, CRA applies to that app as a product with digital elements. You need CRA conformity assessment for the product and EUDIW certification for the wallet service. Neither satisfies the other. Both must be completed independently and maintained under separate surveillance cycles. If you provide the wallet purely as an ICT service with no separately distributed mobile app, CRA does not apply to you through this scheme.

If your products will eventually be subject to a CSA certification scheme under CRA's Article 27 pathway, the wallet scheme is your clearest preview of what that evaluation will look like. The methodologies being validated here are the methodologies you will face.

See the conformity assessment decision guide for the current CRA module options while CSA schemes are still pending.

The Certification Infrastructure Today

The CRA conformity landscape currently has four tiers. Default products (the majority) can use Module A self-assessment. Important Class I products can use Module A if they apply harmonized standards, or go to a Notified Body. Important Class II and Critical products require third-party evaluation, with Critical products also needing an applicable CSA scheme where one exists.

The gap: no CSA scheme currently covers CRA essential requirements. That means the Article 27 pathway, where CSA certification triggers presumption of conformity with CRA, is not yet walkable for any product. It exists in the regulation but not in practice.

The EUDI Wallet scheme doesn't fill that gap. But it establishes the model.

The scheme mandates "high" assurance level exclusively, with no lower tiers permitted. The rationale in the document is direct: "all functions provided by the EUDI wallets are security functions, some of them of critical sensitivity" (p.17). The scheme makes the judgment that no wallet function is low-stakes enough to permit self-assessment.

Self-assessment is not just discouraged. It is blocked: "A conformity self-assessment... shall not be permitted" (p.18).

The logic parallels CRA's approach to Important and Critical products. Higher stakes justify stricter conformity routes. The specific threshold differs between regimes, but the principle is identical. When ENISA drafts future CSA schemes for CRA product categories, expect the same reasoning applied to Annex III and IV products.

For current product classification rules under CRA, see the product classification guide.

What the Scheme Requires of Private Companies

The scheme defines a four-stage lifecycle for applicants.

Preparation covers documentation assembly, risk assessment, and gathering assurance evidence for components. This is where your supply chain evidence becomes a blocking dependency, not a best-effort addition.

First evaluation involves design review and dependency analysis. An IT Security Evaluation Facility (ITSEF) reviews your architecture, your trust model, and the conformity status of each component your wallet depends on.

Second evaluation involves functional testing, penetration testing, and vulnerability assessment against the wallet's claimed security functions. This is not a documentation review. Testers actively probe the system.

Maintenance continues after certificate issuance. Annual surveillance is required, including penetration testing on each anniversary. This is not a checkbox. It's a recurring evaluation cost built into the certificate lifecycle.

The certificate is valid for 5 years. The cap is hard. The scheme states no derogation is possible (p.26). When the certificate lapses, the wallet must be deactivated. There is no grace period to negotiate.

The information integrity obligation is sharper than most compliance frameworks. Providing incorrect or incomplete information to the certification body is classified as non-compliance, not nonconformity (p.23-24). The distinction matters: nonconformity triggers a remediation process. Non-compliance can trigger suspension or withdrawal on different grounds.

After notification of a nonconformity, you have 30 days to assess whether the finding is material (p.38). That window doesn't start when you discover the issue. It starts when the certification body notifies you. Organizations that don't have intake processes for conformity notifications will burn that window before anyone reads the email.

Suspension is public. The scheme requires mandatory public disclosure when a certificate is suspended (p.40). Maximum suspension period is 42 days, extendable to 1 year by the national cybersecurity certification authority (NCCA). This is not an internal matter. Your customers and relying parties will see it.

Document retention extends 5 years beyond certificate expiry, including physical product specimens where applicable (p.49). For software products on a 5-year certificate, that's a 10-year evidence chain minimum.

The CRA model requires pre-market conformity assessment and post-market vulnerability management. The wallet scheme requires continuous conformity with annual penetration testing and surveillance throughout the certificate lifecycle. For companies subject to both, the wallet scheme's post-certification obligations are more demanding than CRA's in scope and frequency.

Your Supply Chain Is Now in the Certification Chain

The wallet scheme uses a compositional evaluation model with three distinct layers.

The Wallet Secure Cryptographic Application (WSCA) and its underlying hardware platform are evaluated under EUCC, the EU Common Criteria scheme. This covers the hardware security modules, secure elements, and trusted execution environments that the wallet depends on.

The wallet instance (the software running on the user's device) is evaluated under FiTCEM, the Functional IT Common Evaluation Method, which handles software evaluation where hardware separation isn't feasible.

Wallet services (server-side components, identity issuance, relying party interfaces) are assessed against CEN TS 18072 requirements.

Each layer has its own evaluation path. Your certificate depends on the certificates underneath it.

The scheme is explicit about the burden this places on applicants: you must "gather the assurance documentation for its components, which may imply to have some of them certified" (p.14). "May imply" understates it. If a component lacks the required assurance documentation, your evaluation cannot conclude.

Subcontractor disclosure is exhaustive. Every subcontractor must be listed, along with the extent of conformity assessment applied to their contribution (p.78). There is no generic "we use reputable vendors" category. Each third party either has documented conformity evidence or they don't, and that gap is your problem in the evaluation.

Upstream vulnerability notifications are mandatory in both directions. When a vulnerability affects an ICT product that underlies a composite ICT service, the EUCC certificate holder must inform dependent EUDIW certificate holders (p.43). This is a specific obligation tied to vulnerability disclosures, not a general notification for every certificate change. If your component supplier identifies a vulnerability and doesn't tell you, they are in breach. If they do tell you, you have a 30-day materiality assessment window to respond.

Continuous monitoring doesn't stop at your organizational boundary. When a base component certificate is updated or replaced, the CAB must perform a differential dependency analysis on the changes (p.84). A meaningful update to a dependency triggers a formal CAB assessment of whether your certification scope is affected.

Cloud providers are not exempt. The scheme classifies infrastructure "supplied by provider" (p.61) as a component in scope for supply chain assessment. If your wallet service runs on a cloud platform, that platform's conformity status is part of your evidence package.

The propagation rule is significant: if a nonconformity correction is pending in a base component's certification report, the CAB must assess its impact on the composite ICT service (p.84). If that impact is material, the composite evaluation cannot conclude until the nonconformity is resolved. This is not automatic — it depends on whether the nonconformity is considered material to your service. But a serious open nonconformity in your WSCA supplier's certification report can stop your evaluation from completing.

This is not a hypothetical future model for CRA. The CRA's SBOM obligation (Annex I Part II) and vulnerability monitoring requirements (Articles 13 and 14) operate on the same principle. The wallet scheme shows how those obligations work in practice inside a formal certification framework: documented, bilateral, and blocking.

For how CRA's supply chain obligations will interact with future CSA certification schemes, see Cybersecurity Act 2. For the practical mechanics of SBOM generation and maintenance, see the SBOM generation guide.

What Your Existing Certifications Are Actually Worth

Most manufacturers assume their existing certifications carry weight in new schemes. For EUDIW, the answer depends entirely on which certification you hold and how rigorously your auditor mapped its scope to the scheme's criteria.

The scheme addresses this directly in Section 5.3. It allows CABs to rely on prior work, but the conditions are strict. A bridge letter is required when there's a gap between the prior audit's reporting period and the current evaluation (p.85). Partial reliance is common; full reliance is rare.

The ISO 27001 finding deserves direct attention. The scheme states plainly: "it does not, on its own, provide sufficient assurance that the individual controls selected in the statement of applicability are designed and operating at the level of rigour required by this scheme" (p.88).

The logic here applies beyond EUDIW. ISMS certification confirms process maturity and that a management system exists. It does not confirm that individual controls work at the level of assurance a specific scheme demands. The same reasoning will apply under CRA when harmonized standards are finalized.

If your SOC 2 Type II audit was scoped without EU cybersecurity criteria in mind, it won't qualify for conditional reliance. You'd need verified mapping from your auditor. Plan for that conversation now, before you're in a certification timeline.

For a deeper comparison of what ISO 27001 actually covers versus CRA requirements, see our ISO 27001 comparison guide.

Vulnerability Management Goes Beyond CRA

The EUDIW scheme's vulnerability management requirements draw explicitly from CRA. The scheme states: "This section... mostly draws from other regulations, such as CSA's Article 55... and also from the CRA" (p.43). That lineage matters because the requirements share structure but diverge on mechanics.

On SBOM: the scheme requires machine-readable format (p.43), aligned with CRA Annex I Part II. This isn't a new concept if you're already tracking CRA obligations, but it confirms that SBOM as a technical artifact is becoming a baseline expectation across EU schemes, not just CRA-specific.

Security updates must be delivered separately from functional updates (p.43). This is operationally significant. A combined release that patches vulnerabilities and adds features creates ambiguity about what users are accepting. The scheme treats them as distinct obligations.

Your CVD policy must be public and aligned with EN ISO/IEC 29147 (p.47). This isn't a policy document buried in a compliance folder. It needs to be findable, current, and structured to the standard.

On impact analysis: CVSS scores alone are insufficient. The scheme requires context-specific analysis (p.44). A CVSS 9.8 in one deployment context may be a CVSS 4.0 in yours, but you need to document that reasoning, not just assert it.

The most operationally significant requirement: a material vulnerability with no remediation path triggers certificate withdrawal (p.45). This creates a direct link between your patch cadence and your certification status. The clock doesn't stop at assessment.

The CRA comparison matters here. CRA requires ENISA notification within 24 hours of discovering an actively exploited vulnerability. EUDIW uses "without undue delay" through the CAB chain. Different clock, different routing, similar intent. If you're building processes for one, design them to satisfy both.

For a breakdown of the 24-hour reporting obligation specifically, see our post on ENISA vulnerability reporting. For a starting point on your CVD policy, see the CVD policy template.

What Is Confirmed vs. Our Analysis

Five Things to Watch

The scheme is not final. The April 30 consultation deadline means changes are still possible. These are the areas where the outcome materially affects your planning.

1. Evidence format requirements: The scheme references machine-readable SBOMs and technical file structure but doesn't fully standardize what "sufficient" looks like in practice. CABs will interpret this. Until they do, build toward the most structured format you can defend.

2. CAB capacity: Authorization requires both accreditation and NCCA sign-off, plus completion of a pilot evaluation (p.30). The bootstrapping problem is real. If qualified CABs are scarce when the scheme enters force, timelines slip regardless of how prepared you are. This is not within your control, but it affects your scheduling assumptions.

3. Mutual recognition: The scheme does not adopt the EUCC mutual recognition provisions for third-country schemes (p.52). Third-country mutual recognition is explicitly left open for a later phase: "these conditions may be added in a later phase." This is unresolved, not settled. Don't plan on your US certifications traveling, but this is an active open question rather than a permanent rejection.

4. National scheme sunset: Existing national schemes have a 12-month window after entry into force to remain valid (p.56). If your current certification is issued under a national scheme, understand when that window closes.

5. Open questions: Penetration testing ownership, attack potential level thresholds, and the depth qualifiers for vulnerability analysis remain unresolved in the current text (p.97-98). These are not editorial gaps. They affect how you scope and budget assessments.

What We Know for Certain

• CRA is explicitly cited as a source for the scheme's requirements.
• SBOM in machine-readable format is required.
• ISO 27001 alone does not satisfy organizational control requirements.
• Self-assessment is not available at any assurance level for EUDIW components.
• Certification validity is capped at 5 years.

Our Analysis (Not Confirmed)

• CRA conformity assessment schemes will likely follow similar patterns on SBOM requirements, CVD policy, and the insufficiency of ISO 27001 in isolation. The EUDIW scheme gives a preview of how ENISA thinks about these obligations.
• Supply chain certification pressure will increase. EUDIW's component-level requirements suggest that downstream manufacturers will start requiring upstream suppliers to hold independent certifications, not just self-declarations.
• SOC 2 mapping is a real opportunity. If you engage your auditor now to structure criteria mapping against EU cybersecurity requirements, you may position your next SOC 2 Type II for conditional reliance rather than starting from scratch.

What Nobody Knows Yet

• When a CRA-specific certification scheme will be published and what its consultation timeline looks like.
• Which harmonized standards will be designated under CRA and what assurance thresholds they will set.
• How national CAB capacity will develop relative to demand when multiple schemes are active simultaneously.

What Manufacturers Should Do Now

The consultation window and final scheme publication give you a defined window to prepare. These are concrete steps, not general advice.

• Understand your conformity assessment route. The scheme's assurance levels map to different product categories. What applies to you isn't always obvious. Use a structured decision process before assuming you know your path. Start with our conformity assessment decision guide.

• Build evidence now. SBOMs, risk assessments, vulnerability disclosure policies, and technical files take time to produce correctly. Starting during the consultation period means you can iterate before a CAB is asking for them.

• Don't assume ISO 27001 covers you. The scheme is explicit. If your compliance posture is built on ISO 27001 as a proxy for cybersecurity assurance, you have a gap. Identify which controls need independent verification.

• Structure your next SOC 2 with EU criteria mapping in mind. If you're due for a SOC 2 renewal, talk to your auditor before scoping begins. Documented criteria mapping to EUDIW (and eventually CRA) requirements is what converts a Type II from partial to conditional reliance.

• Track the consultation process. The April 8 webinar and April 30 written deadline are the last formal input points before the scheme moves toward finalization. If the scheme affects your products, submit comments or at minimum monitor what changes.

• Map your supply chain. Identify which upstream components are covered by the scheme's scope. If a supplier can't demonstrate certification for a component you integrate, that gap becomes your problem at assessment time.

How CRA Evidence Helps

CRA Evidence supports the documentation and process infrastructure that EUDIW and CRA assessments require:

• SBOM management: Generate, store, and export SBOMs in machine-readable formats aligned with CRA Annex I Part II requirements.
• VDP with CVD workflow: Publish and manage your vulnerability disclosure policy with a structured intake and response workflow aligned to EN ISO/IEC 29147.
• ENISA notification tracking: Track the 24-hour, 72-hour, and 14-day reporting windows with audit-ready records for each notification.
• Supplier portal: Manage upstream and downstream notifications within your supply chain, with documented evidence of communication for technical files.

See what CRA Evidence covers at craevidence.com.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.