ECSMAF v3.0 Explained: How ENISA Maps the EU Cybersecurity Market

What Is ECSMAF v3.0, and Why Should You Care?

In March 2026, ENISA published the third version of its Cybersecurity Market Analysis Framework. This is not a market report. It is the methodology that ENISA and partner institutions use to conduct structured market analyses of the EU cybersecurity sector, mandated under EU Cybersecurity Act Article 8(7).

The framework defines a 7-step workflow covering everything from scoping a market segment to collecting data and presenting findings. ENISA has already applied earlier versions to three major analyses: cloud cybersecurity (2023), cryptographic products and services (2024), and managed security services (2025).

flowchart LR
    S1["1. Initiate"]
    S2["2. Scope"]
    S3["3. Analyse\nSegment"]
    S4["4. Define\nQuestions"]
    S5["5. Collect\nData"]
    S6["6. Analyse\nData"]
    S7["7. Present\nResults"]

    S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7

    style S1 fill:#1a3a5c,color:#fff,stroke:#0d6efd
    style S2 fill:#1a3a5c,color:#fff,stroke:#0d6efd
    style S3 fill:#1a3a5c,color:#fff,stroke:#0d6efd
    style S4 fill:#2c5f8a,color:#fff,stroke:#0d6efd
    style S5 fill:#2c5f8a,color:#fff,stroke:#0d6efd
    style S6 fill:#2c5f8a,color:#fff,stroke:#0d6efd
    style S7 fill:#1a3a5c,color:#fff,stroke:#0d6efd

What ENISA measures shapes where EU funding, procurement, and policy attention flow. Product categories that appear in the framework will show up in ENISA's market reports and the data that policymakers reference. Categories that do not appear will not.

What Actually Changed from v2.0 to v3.0

ENISA's previous framework versions treated cybersecurity market analysis as a one-shot exercise: scope a segment, collect data, publish a report, move on. After applying this approach to three real studies, ENISA found the model too rigid. Reports took too long. Results went stale. The framework could not keep pace with regulatory deadlines. Version 3.0 addresses these shortcomings with three structural changes.

Configurable workflows replace the one-size-fits-all process. V3.0 introduces four distinct analysis pathways based on two variables: initiation (planned vs. ad hoc request) and duration (short, under six months, vs. long).

Companies benefit because ENISA can now produce fast-turnaround market assessments when a regulation creates sudden demand for segment-specific intelligence, rather than waiting a year for a comprehensive study.

Continuous Market Monitoring is the headline addition. V3.0 introduces a concept borrowed from system operations: a "(semi-)automated process" that tracks market events like product vulnerabilities, certificate issuances, and company acquisitions. When monitoring detects a relevant event, a market analysis can be initiated to assess its impact. The framework explicitly ties this capability to CRA implementation phases. As CRA provisions take effect (SBOM requirements, security controls, vulnerability handling obligations), the volume of structured, product-level data available for monitoring increases. ENISA expects continuous monitoring needs to emerge once "a certain CRA maturity level has been reached through the adoption of CRA provisions by vendors." Until then, ENISA states that "the most frequent types of market analysis are expected to remain one-off." The agency is laying the groundwork to detect systemic risks (a critical OSS vulnerability affecting thousands of CRA-regulated products, for example) and assess market impact, but this capability is contingent on CRA adoption maturing first.

Regulatory alignment is structural, not cosmetic. The CRA appears in asset identification, threat assessment, security requirements, and continuous monitoring sections. It is treated as a structural input alongside NIS 2 and other EU regulations.

flowchart TD
    CRA["CRA Provisions Take Effect"]
    SBOM["SBOMs"]
    SC["Security Controls"]
    PC["Product Categorisation\n(Annex III / IV)"]
    VD["Vulnerability Disclosures"]

    CRA --> SBOM
    CRA --> SC
    CRA --> PC
    CRA --> VD

    AGG["Aggregate Market-Level Data\nGrows Across Industry"]
    SBOM --> AGG
    SC --> AGG
    PC --> AGG
    VD --> AGG

    AGG --> CMM["ENISA Continuous\nMarket Monitoring"]
    CMM --> |"Event detected"| AH["Ad Hoc\nMarket Analysis"]
    CMM --> |"Periodic"| REC["Recurrent\nMarket Analysis"]

    style CRA fill:#1a3a5c,color:#fff,stroke:#0d6efd
    style AGG fill:#2c5f8a,color:#fff,stroke:#0d6efd
    style CMM fill:#0d6efd,color:#fff,stroke:#0d6efd
    style AH fill:#198754,color:#fff,stroke:#198754
    style REC fill:#198754,color:#fff,stroke:#198754
    style SBOM fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6
    style SC fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6
    style PC fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6
    style VD fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6

Section 5 specifically addresses how CRA-mandated data will feed continuous monitoring pipelines. For companies already investing in CRA compliance tooling, the implication is concrete: as CRA provisions take effect, the volume of structured product-level data across the market will grow. That aggregate data is what ENISA plans to use for continuous market monitoring. The compliance infrastructure you build today feeds the data ecosystem ENISA is designing around.

How ENISA Maps the Cybersecurity Supply Side

Annex G defines eight "value stack" groups that classify every cybersecurity supplier in Europe. If you sell CRA compliance tooling, you need to know where you sit in this taxonomy. It determines how ENISA counts you, how policymakers see your market segment, and increasingly, how procurement teams filter vendors.

The eight groups, with the subcategories most relevant to CRA:

1. R&D and Education. Two value stacks: Education (training programmes, awareness platforms) and R&D (threat research, standards and certification R&D, security for AI/emerging tech). If you contribute to CRA standards development, ENISA tracks you here.

2. Software. The largest group by subcategory count. Seven value stacks: Application Security Software (vulnerability assessment, secure development tools), Cloud Security Software, Data Security Software, Identity and Access Management Software, Infrastructure Protection Software (endpoint/XDR), Operational Platforms (SIEM, SOAR, threat intelligence), and Integrated Risk Management / GRC Software (digital risk management, vendor risk management, audit and compliance management, legal oversight). SBOM generation, vulnerability tracking, and CRA compliance dashboards fall under this GRC bucket. If your product helps manufacturers build technical files or manage coordinated vulnerability disclosure, this is your ENISA home.

3. Hardware. Network security equipment, hardware security modules, TPMs, biometric devices. Relevant if you build physical products with digital elements that need CRA conformity assessment themselves.

4. Distribution. Software resale, hardware resale, managed services resale. Channel partners, not builders.

5. Advisory and Consulting. Professional services: cybersecurity strategy, penetration testing, compliance and audit services, digital forensics, SOC design. Third-party CRA gap assessments and conformity consulting sit here.

6. Implementation Services. Design and integration: security architecture, interoperability services, technical implementation support. The firms that deploy and configure the tools.

7. Managed Services. Four value stacks: managed detection/response, device management (patching, decommissioning), threat and vulnerability services, and virtualised/as-a-service cybersecurity. Ongoing CRA vulnerability monitoring as a managed offering fits this group.

8. Certification Services. Three distinct value stacks that ENISA separates carefully. Product Certification covers services for product security certification: requirements definition, evaluation, controls, and testing. This is where CRA conformity assessment bodies and their tooling live. Service and Process Certification covers audits, gap analysis, and accreditation of labs and processes. Professional Certification covers individual credential programmes, exam development, and accreditation of testing organisations.

Where CRA compliance tooling fits in the value stack:

flowchart TD
    subgraph BUILD["Build & Secure"]
        RD["R&D &\nEducation"]
        SW["Software\n(7 value stacks)"]
        HW["Hardware"]
    end

    subgraph DELIVER["Deliver & Operate"]
        DIST["Distribution"]
        IMPL["Implementation\nServices"]
        MS["Managed\nServices"]
    end

    subgraph ADVISE["Advise & Certify"]
        ADV["Advisory &\nConsulting"]
        CERT["Certification\nServices"]
    end

    SW -.- |"GRC Software\nSBOM, vuln tracking,\ncompliance dashboards"| CRA_TOOL["Your CRA\nCompliance\nTooling"]
    CERT -.- |"Product Certification\nConformity assessment"| CRA_TOOL
    ADV -.- |"Compliance & Audit\nGap assessments"| CRA_TOOL

    style CRA_TOOL fill:#0d6efd,color:#fff,stroke:#0d6efd,stroke-width:2px
    style SW fill:#1a3a5c,color:#fff,stroke:#0d6efd
    style CERT fill:#1a3a5c,color:#fff,stroke:#0d6efd
    style ADV fill:#1a3a5c,color:#fff,stroke:#0d6efd
    style RD fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6
    style HW fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6
    style DIST fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6
    style IMPL fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6
    style MS fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6

How to use Annex G for positioning: Read Table 4 as a market map, not just a classification exercise. Identify which value stack group your product's primary function falls into, then check whether secondary features push you into adjacent stacks. A CRA compliance SaaS platform is primarily GRC Software, but if it includes automated vulnerability scanning, it also touches Application Security Software. If it generates conformity documentation, it overlaps with Product Certification tooling. ENISA's future market sizing reports will use these categories as examples (the framework notes they may vary by sector). Understanding where you sit helps align your positioning with the vocabulary policymakers use.

The CRA Is Now Baked Into How Europe Analyses Cybersecurity Markets

ECSMAF v3.0 is the first EU analytical framework that treats the Cyber Resilience Act as a structural input to market intelligence, not a background consideration. The executive summary opens by naming the Cyber Resilience Act as one of the key legislative requirements shaping the EU cybersecurity market. The CRA is the first regulation cited in that sentence, and it is referenced throughout the framework — but NIS 2, DORA, and the AI Act all appear in the scoping criteria (Annex E) as regulations shaping demand.

CRA product categories inform asset identification. When analysing products with digital elements, ECSMAF directs analysts to use CRA Annex III (Important products) and Annex IV (Critical products) to identify which parts count as assets (Sections 3.5.2 and 4.5.2). Future ENISA market reports covering digital products will therefore reference the same product categories that determine your conformity assessment obligations.

For segments linked to critical sectors (NIS 2 critical infrastructure, CRA-critical products), the threat analysis must also include "both high-impact and low-probability scenarios" (Sections 3.5.4 and 4.5.4). Procurement officers and regulators are likely to use these ENISA reports as reference material when evaluating vendors.

Open-source software gets a three-way split. Section 5 introduces a distinction that aligns with the CRA's categories for open source. When a vulnerability is detected in an OSS component, ECSMAF requires analysts to differentiate between three categories:

flowchart LR
    VULN["OSS Vulnerability\nDetected"]

    VULN --> A["Community-Driven\n(Non-commercial)"]
    VULN --> B["Steward-Managed\n(e.g. Foundation)"]
    VULN --> C["Commercial OSS\n(CRA 'Manufacturer')"]

    A --> RA["Systemic supply-chain\nrisk assessment"]
    B --> RB["Evaluate steward's\nvulnerability management"]
    C --> RC["Contained vendor\nissue — standard\nmarket response"]

    style VULN fill:#dc3545,color:#fff,stroke:#dc3545
    style A fill:#ffc107,color:#1a3a5c,stroke:#ffc107
    style B fill:#fd7e14,color:#fff,stroke:#fd7e14
    style C fill:#198754,color:#fff,stroke:#198754
    style RA fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6
    style RB fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6
    style RC fill:#f8f9fa,color:#1a3a5c,stroke:#dee2e6

This classification matters because it determines whether a market event signals systemic supply-chain risk or a contained vendor issue. A critical vulnerability in a widely-reused community-driven library (category a) could affect thousands of CRA-regulated products — triggering a different market response than the same vulnerability in a single vendor's commercial offering (category c).

The framework also references (in footnotes) the Eclipse Foundation's OCCTET project, the Open Source Security Foundation's Linux Foundation Express Learning 1001 course, and the Eclipse Open Regulatory Compliance Working Group as examples of emerging community-driven compliance resources.

The demand-side survey captures regulatory procurement signals. Annex L's demand-side questionnaire template asks buyers to report on several areas that map directly to CRA compliance decisions:

While the template is generic (it does not name the CRA specifically), the questions on certifications, assurance levels, and self-assessment map directly to the conformity assessment choices manufacturers face under the CRA. When ENISA applies this template to a market segment that includes CRA-regulated products, the results will provide structured, EU-wide data on how regulatory requirements are shaping procurement decisions.

The supply-side survey asks vendors directly. Annex L also includes a supply-side questionnaire template. If you are surveyed by ENISA, expect questions on:

• Certifications you hold, renewal frequency, and barriers to certification
• Certifications your customers are demanding
• Delivery model (on-premises, cloud, hybrid, outsourced)
• Most frequently encountered customer requirements
• Which EU and national regulations affect your offering
• Incident experience: awareness, impact, mandatory reporting, time to resolution
• Innovation potential: start-ups, scale-ups, EU companies in AI, IoT, OT/IT convergence
• Enterprise size and annual turnover, percentage of revenue from cybersecurity

If you receive an EUSurvey invitation from ENISA, this is the framework behind it.

Continuous monitoring is tied to CRA maturity. Section 5.3 states plainly: "Until a certain CRA maturity level is reached, the most frequent types of market analysis are expected to remain one-off." ENISA expects continuous market monitoring to become feasible only as CRA implementation matures, because CRA provisions (SBOMs, security controls, product categorization) will generate the structured, product-level data that continuous monitoring requires. ENISA's position is clear: the CRA will generate the data infrastructure that enables continuous European cybersecurity market monitoring.

What Else ENISA Will Track

The framework covers several additional areas relevant to CRA manufacturers.

Member States can adopt ECSMAF. The framework is designed to be used not only by ENISA but also by "Member States, sectoral authorities and other public or private actors" (Section 6). National cybersecurity agencies and market surveillance authorities could apply ECSMAF to analyse CRA product segments in their jurisdictions. The methodology you see in this document may become a de facto standard used by multiple regulators across Europe.

Annex E defines exactly how ENISA scopes your market segment. When ENISA decides to analyse a cybersecurity market segment, Annex E (Table 2) lists the criteria analysts use. These are the dimensions that determine how your market is profiled:

ENISA also tracks the origin of venture capital and the financial structure of companies owning strategic products (Section 5). For manufacturers with non-EU headquarters or non-EU investors, this is relevant context.

CRA data, ENISA analysis, and enforcement form a closed loop. CRA Article 17(3) requires ENISA to produce a biennial technical report on emerging cybersecurity risks. ECSMAF uses that report as an input when selecting market segments (footnotes 19, 31, 38). Market analysis findings can then trigger coordinated compliance sweeps targeting specific product categories (Sections 3.8.3 and 4.8.3). Sweep results feed back into the next cycle.

flowchart LR
    CRA["CRA Compliance Data\n(SBOMs, vulnerability\ndisclosures, certificates)"]
    EUVD["EU Vulnerability\nDatabase + ENISA\nBiennial Report\n(Art. 17.3)"]
    ECSMAF["ECSMAF Market\nSegment Selection\nand Analysis"]
    SWEEP["Coordinated\nCompliance Sweeps\n(Sections 3.8.3 / 4.8.3)"]

    CRA --> EUVD
    EUVD --> ECSMAF
    ECSMAF --> SWEEP
    SWEEP --> CRA

    style CRA fill:#1a3a5c,color:#fff,stroke:#0d6efd
    style EUVD fill:#2c5f8a,color:#fff,stroke:#0d6efd
    style ECSMAF fill:#0d6efd,color:#fff,stroke:#0d6efd
    style SWEEP fill:#dc3545,color:#fff,stroke:#dc3545

This means the compliance infrastructure you build today (SBOMs, vulnerability handling processes, conformity documentation) does not sit in a filing cabinet. It enters a data ecosystem that ENISA uses for market analysis, which can inform enforcement actions, which generates more data for the next round.

Barriers to adoption are formally catalogued. Annex I (Table 5) lists 28 structural barriers across 8 categories that ENISA will assess in each market segment. The ones most relevant to CRA manufacturers:

These are not hypothetical concerns. They are formal categories in ENISA's analytical framework, and ENISA will assess each market segment against them.

ENISA harvests data from GitHub, VC databases, and business registries. Annex K lists the secondary data sources ENISA uses:

• Business and investment databases for ownership and market share data
• GitHub and open-source repositories for tracking tooling innovation
• Investment banks and venture funds for funding flow analysis
• Standardisation body databases for compliance mapping
• Technology news outlets and trade publications for early signals of change

Your public presence across these sources is part of the data ENISA analyses.

The Consultant's Edge: Proving Alignment to Clients

If you sell cybersecurity products or services to European organisations, ECSMAF v3.0 gives you something valuable: ENISA's own vocabulary to describe what you do.

Map your capabilities to specific Annex G value stack categories. When pitching to EU clients, the sentence "Our solution addresses the [specific ECSMAF category]" gives you third-party vocabulary from the EU's cybersecurity agency, which resonates more with EU procurement teams than feature-level comparisons.

Three Ways to Use ECSMAF v3.0 Categories Today

1. Map Your Product to the Value Stack

Using the value stack groups from Annex G described above, identify where your product's primary function falls and whether secondary features place you in adjacent stacks.

Note: your Declaration of Conformity and technical file must reference harmonised standards and conformity assessment procedures under the CRA, not ENISA's market categories.

2. Benchmark Your Evidence Against Demand-Side Criteria

The demand-side survey template (Annex L) lists what organisations look for when selecting cybersecurity providers. Use this as a self-audit checklist:

• [ ] Can you demonstrate which certifications you hold (product, service, professional staff)?
• [ ] Can you articulate your compliance posture against applicable EU regulations (CRA, NIS 2)?
• [ ] Do you have documented incident handling and mandatory reporting capabilities?
• [ ] Can you explain at which assurance level your product has been evaluated?
• [ ] Where self-assessment applies, do you have the evidence to back your claims?

Gaps in any of these areas are likely to surface during procurement evaluations.

3. Position Your CRA Investment Using ENISA's Framework

When presenting CRA investment to leadership or investors, reference the ECSMAF taxonomy directly: "Our compliance investment maps to [category], a segment ENISA has identified for future Continuous Market Monitoring as CRA adoption matures." This positions CRA spend as strategic market investment rather than pure regulatory cost, backed by ENISA's own framework categories.

Quick Reference: Where to Find What in ECSMAF v3.0

The Bottom Line

ENISA is building the analytical framework for the EU cybersecurity market, and ECSMAF v3.0 is the methodology. Companies that understand it and speak ENISA's taxonomy will navigate EU procurement and compliance more effectively than those who have not aligned their positioning with it.

Official Sources

• ENISA Cybersecurity Market Analysis Framework (ECSMAF) v3.0 (PDF)
• ENISA publication page

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