Article 24: Use of European cybersecurity certification schemes

Article 24: use of european cybersecurity certification schemes requirement means you must be ready to adopt EU cybersecurity certification (under the EU Cybersecurity Act) for specific ICT products, services, or processes when your Member State makes certification mandatory to evidence compliance with parts of NIS 2 Article 21. Operationally, track national transposition, map certification to controls, and bake certification checks into procurement and architecture decisions. (Directive (EU) 2022/2555, Article 24)

Key takeaways:

• Treat certification as a potential mandatory control mechanism for selected Article 21 measures, not a generic “nice-to-have.” (Directive (EU) 2022/2555, Article 24)
• Your fastest path to execution is procurement gating: define which technology classes require EU certification evidence before purchase or renewal. (Directive (EU) 2022/2555, Article 24)
• Build an audit-ready repository of certificates, scope statements, validity dates, and exceptions tied to systems and suppliers. (Directive (EU) 2022/2555, Article 24)

Article 24 sits at the junction between NIS 2 security risk management (Article 21) and the EU’s cybersecurity certification ecosystem under Regulation (EU) 2019/881 (the EU Cybersecurity Act). The practical consequence for a CCO or GRC lead is straightforward: in some Member States and for some requirements, regulators can demand that essential and important entities demonstrate compliance by using certified ICT products, ICT services, or ICT processes. (Directive (EU) 2022/2555, Article 24)

That “may require” phrasing matters. You cannot assume certification is optional everywhere, and you also cannot assume that any certificate will do. The obligation is triggered by national rules (transposition and supervisory expectations), and it is meant to evidence compliance with “particular requirements” of Article 21. (Directive (EU) 2022/2555, Article 24)

To operationalize quickly, treat Article 24 as a readiness requirement: establish a mechanism to (1) detect when your jurisdictions mandate EU certification for specific technology categories, (2) enforce those requirements through procurement/third-party due diligence and solution architecture, and (3) preserve evidence that is exam-ready.

Regulatory text

What the law says (operator-relevant excerpt). NIS 2 allows Member States, for purposes of demonstrating compliance with particular requirements of Article 21, to require essential and important entities to use specific ICT products, ICT services, and ICT processes (whether developed internally or procured from third parties) that are certified under European cybersecurity certification schemes adopted under Article 49 of Regulation (EU) 2019/881. It also directs Member States to encourage entities to use such certified products, services, and processes. (Directive (EU) 2022/2555, Article 24)

What you must do with that text.

1. Assume certification can become a condition of compliance for selected Article 21 controls in the jurisdictions where you operate. Your compliance position must be “we know which tech categories are in scope and we can prove certification status.” (Directive (EU) 2022/2555, Article 24)
2. Treat third-party sourcing as explicitly in scope. The article covers items “procured from third parties,” so your third-party due diligence and contracting motions must support certification verification and ongoing validity monitoring. (Directive (EU) 2022/2555, Article 24)
3. Plan for selectivity. The requirement is not “certify everything.” It is “use particular ICT products/services/processes” where Member States require them to demonstrate compliance with particular Article 21 requirements. Your job is to build the switch that can be flipped per category and jurisdiction. (Directive (EU) 2022/2555, Article 24)

Plain-English interpretation (requirement-level)

If your organization is an essential entity or important entity under NIS 2, your regulator may expect you to use EU-certified cybersecurity products/services/processes for certain high-impact use cases (for example, technology supporting security monitoring, identity, or managed services), because certification can serve as proof you meet parts of Article 21. Your operational target is simple: no one should be able to buy or deploy a “regulated technology class” without either (a) documented EU certification evidence or (b) an approved exception with compensating controls and a remediation plan. (Directive (EU) 2022/2555, Article 24)

Who it applies to (entity and operational context)

In scope entities

• Essential entities and important entities under NIS 2, as categorized by Member State implementation and your sector/size and criticality. (Directive (EU) 2022/2555, Article 24)

In scope operational contexts

• Procurement and third-party onboarding for ICT products and services where certification is required or becomes a supervisory expectation. (Directive (EU) 2022/2555, Article 24)
• Technology architecture and engineering decisions for internally developed ICT processes or platforms that fall into “particular” categories a Member State mandates to be certified. (Directive (EU) 2022/2555, Article 24)
• Control assurance for Article 21 where certification is used to demonstrate compliance, meaning audits/exams will ask for certificate scope, validity, and mapping to your control baseline. (Directive (EU) 2022/2555, Article 24)

What you actually need to do (step-by-step)

1) Create a jurisdiction-aware “certification applicability” register

Build a small register (sheet or GRC object) with:

• Member State jurisdiction(s) where you operate
• Whether national rules require EU cybersecurity certification for any ICT categories to evidence Article 21 controls
• Technology categories affected (define categories you can enforce in procurement)
• Owner (GRC) and enforcement point (Procurement, Architecture Review Board, Security Engineering) (Directive (EU) 2022/2555, Article 24)

Daydream fit: Daydream can act as the obligation register system of record with owners, milestones, and mapped evidence objects so you can show supervisors a single, controlled view of what applies where.

2) Define “regulated technology classes” you can gate

Pick categories that map cleanly to purchasing and deployment decisions, such as:

• Identity and access management components
• Managed security services and security monitoring tools
• Endpoint protection and network security controls
• Cloud services supporting critical systems

Keep the list short and enforceable. If you cannot gate it, you cannot defend it in an exam. (Directive (EU) 2022/2555, Article 24)

3) Add certification checks into procurement and third-party due diligence

Update your intake and due diligence workflow to require, for in-scope categories:

• Certificate name and scheme (as applicable)
• Certificate ID/reference (as issued)
• Scope statement (product/service/process and version coverage)
• Validity period and renewal expectations
• Any limitations or conditions called out in the certificate documentation (Directive (EU) 2022/2555, Article 24)

Contracting controls to add

• Representation that the in-scope offering remains certified for the contracted term (or notice obligations if status changes)
• Right to receive updated certificates and audit artifacts
• Right to terminate or require remediation if certification lapses for mandated categories (Directive (EU) 2022/2555, Article 24)

4) Map certifications to Article 21 control outcomes (don’t stop at “we have a cert”)

Build a lightweight crosswalk:

• Article 21 requirement area you are trying to evidence (for example, supply chain assurance, secure development, vulnerability management)
• Which system/service uses the certified product/service/process
• What risk remains outside the certificate scope
• Compensating controls for uncovered scope (Directive (EU) 2022/2555, Article 24)

This prevents a common audit failure: presenting a certificate that does not cover the actual deployed configuration or operational use.

5) Establish exception handling and compensating controls

You need an exception path because certification coverage may be limited for some categories or legacy stacks. Minimum exception record:

• Business justification
• Risk assessment
• Compensating controls (technical and procedural)
• Time-bounded remediation plan (for example, replacement at renewal, migration plan, or certification roadmap commitment from the third party)
• Approval by accountable risk owner (Directive (EU) 2022/2555, Article 24)

6) Continuous monitoring: certificate validity and scope drift

Create a recurring control to confirm:

• Certificate remains valid
• Product/service version in use stays within certificate scope
• Critical subcontractors or delivery model changes do not invalidate the certification posture (Directive (EU) 2022/2555, Article 24)

This is a practical third-party risk management issue: certification evidence goes stale unless you manage it like any other assurance artifact.

Required evidence and artifacts to retain (exam-ready)

Store these in a controlled repository linked to systems and suppliers:

• Certification documents (certificate, annexes, scope statements) for each in-scope ICT product/service/process (Directive (EU) 2022/2555, Article 24)
• Procurement records showing certification was checked pre-award (intake forms, due diligence checklist output, approval trail) (Directive (EU) 2022/2555, Article 24)
• Contract clauses and supplier commitments related to certification maintenance and notification (Directive (EU) 2022/2555, Article 24)
• System inventory mapping: which critical services rely on certified components (Directive (EU) 2022/2555, Article 24)
• Exceptions register with approvals and compensating controls (Directive (EU) 2022/2555, Article 24)
• Ongoing monitoring evidence: periodic re-verification notes, supplier attestations, renewal tracking (Directive (EU) 2022/2555, Article 24)

Common exam/audit questions and hangups

Expect supervisors and internal audit to press on these points:

• “Which Member State requirement are you following?” Have your jurisdictional applicability register ready. (Directive (EU) 2022/2555, Article 24)
• “Show me where certification is required vs encouraged.” Separate “mandatory” from “recommended” in your register and procedures. (Directive (EU) 2022/2555, Article 24)
• “Does the certificate cover your deployed version and delivery model?” Provide scope statements tied to your asset inventory and configuration baselines. (Directive (EU) 2022/2555, Article 24)
• “What happens if certification lapses?” Show contract language, monitoring control, and your exception/remediation workflow. (Directive (EU) 2022/2555, Article 24)
• “How does this evidence Article 21?” Produce the crosswalk from certification artifacts to specific Article 21 control objectives you rely on it for. (Directive (EU) 2022/2555, Article 24)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Treating Article 24 as “optional certification guidance” everywhere	Member States can make it mandatory for demonstrating compliance with parts of Article 21. (Directive (EU) 2022/2555, Article 24)	Track national transposition by jurisdiction and formalize procurement gates tied to that register.
Collecting a certificate PDF but not the scope/version	Certificates often have constraints; audits test applicability. (Directive (EU) 2022/2555, Article 24)	Require scope statement and version mapping as part of due diligence intake.
Applying checks only to new purchases	Legacy tech often supports critical services. (Directive (EU) 2022/2555, Article 24)	Run a retrospective inventory review for in-scope categories; open remediation tickets or exceptions.
No plan for lapsed certification	Certification can expire or change with product updates. (Directive (EU) 2022/2555, Article 24)	Add renewal tracking and contract notice obligations; define operational playbook for lapse events.
Over-scoping the program (“certify everything”)	Creates unmanageable burden and weak enforcement. (Directive (EU) 2022/2555, Article 24)	Start with a short list of regulated technology classes and expand only when mandated.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should plan around supervisory examination risk rather than case-law patterns. Practically, Article 24 failures tend to show up as:

• inability to prove that required certified technologies were selected for in-scope use cases, and/or (Directive (EU) 2022/2555, Article 24)
• mismatches between “certified” claims and what is deployed in production, and/or (Directive (EU) 2022/2555, Article 24)
• procurement and third-party governance gaps where certification evidence is missing, outdated, or not contractually enforceable. (Directive (EU) 2022/2555, Article 24)

Treat this as a control-evidence problem with supply chain implications.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and gating)

• Stand up the jurisdictional applicability register for Article 24 and assign an owner. (Directive (EU) 2022/2555, Article 24)
• Define your initial regulated technology classes and where the gate will be enforced (procurement intake, architecture review, security exception committee). (Directive (EU) 2022/2555, Article 24)
• Update procurement intake to capture certification status fields and require evidence attachments for in-scope categories. (Directive (EU) 2022/2555, Article 24)

Days 31–60 (operationalize evidence and contracts)

• Build the certification-to-Article 21 crosswalk for the categories you gated, so you can explain what the certification is evidencing. (Directive (EU) 2022/2555, Article 24)
• Update contract templates and playbooks to include certification maintenance/notice clauses for relevant third parties. (Directive (EU) 2022/2555, Article 24)
• Create an exceptions workflow and a standard compensating controls menu for common gaps. (Directive (EU) 2022/2555, Article 24)

Days 61–90 (clean up legacy and prove readiness)

• Perform a retrospective review of existing critical suppliers and systems in the regulated technology classes; collect missing certificates or file exceptions with remediation owners. (Directive (EU) 2022/2555, Article 24)
• Implement certificate validity tracking (calendar-based control plus quarterly review meetings with procurement and security architecture). (Directive (EU) 2022/2555, Article 24)
• Run a tabletop “exam request”: produce, on demand, your register, crosswalk, sample certificates, and an exception record within a short internal SLA. (Directive (EU) 2022/2555, Article 24)

Frequently Asked Questions

Does Article 24 mean we must certify all of our systems?

No. Article 24 allows Member States to require certified ICT products, services, or processes for particular Article 21 requirements, and it also calls for encouragement of certification. Your program should focus on categories your Member State makes mandatory or your supervisor expects for critical use cases. (Directive (EU) 2022/2555, Article 24)

We buy a service from a third party. Who is responsible for the certification evidence?

You are responsible for being able to demonstrate compliance, even if the certified item is procured from a third party. Make certification proof a due diligence requirement and a contractual obligation to keep evidence current. (Directive (EU) 2022/2555, Article 24)

What evidence will an auditor actually want to see?

Expect requests for the certificate, its scope/version coverage, proof you checked it before contracting, and a mapping that explains which Article 21 requirement the certification is supporting. Also expect to show how you track expiry and scope drift. (Directive (EU) 2022/2555, Article 24)

If our Member State only “encourages” certification, do we still need a process?

Yes. Keep a lightweight process so you can show you considered certification for high-impact purchases and can pivot quickly if the national rule changes from encouraged to required for certain categories. (Directive (EU) 2022/2555, Article 24)

How do we handle legacy products that are not certified?

Document them in an exception register with compensating controls and a remediation plan tied to refresh cycles or supplier roadmaps. Link the exception to the affected system inventory so you can answer exam questions quickly. (Directive (EU) 2022/2555, Article 24)

Can we rely on a supplier’s marketing claim that they are “EU certified”?

Don’t. Require the actual certification artifact and confirm scope and validity match what you are buying and operating. Store it with your third-party due diligence record. (Directive (EU) 2022/2555, Article 24)