The EU Cyber Resilience Act and a Networked RFID Reader: Clocks, Classes and Clauses

If you sell a networked RFID reader into the European Union, the Cyber Resilience Act is already acting on you — not in December 2027, now. Reporting switched on in September 2026, it reaches products you shipped years ago, and one classification question decides whether you self-assess or need a notified body. That question turns on the declared intended purpose: the same physical reader lands in different categories depending on what you sold it for. Below are the clauses, the reporting clocks worked out in dates, and the route a Class I reader takes today.

The deadline already running

Three dates matter and two have passed. Article 71(2) of Regulation (EU) 2024/2847 says the Regulation applies from 11 December 2027 — then adds that Article 14 applies from 11 September 2026 and Chapter IV (Articles 35 to 51) from 11 June 2026. Article 14 is the reporting article; Chapter IV is headed Notification of conformity assessment bodies, and starts early so notified bodies exist before anyone needs one.

Derive the entry-into-force date rather than copying it, because secondary sources circulate it both ways. Article 71(1) uses the standard formula — in force “on the twentieth day following that of its publication”. The reference on the face of the act is OJ L, 2024/2847, 20.11.2024; counting from the day after publication, 21 November as day one, the twentieth day is 10 December 2024. The act closes Done at Strasbourg, 23 October 2024. A deck saying 11 December has added a day.

The Commission states the duty plainly: as of 11 September 2026, manufacturers report actively exploited vulnerabilities and severe incidents. ENISA’s Single Reporting Platform went live that day.

What the CRA counts as the product

Article 3(1) defines a product with digital elements as a software or hardware product and its remote data processing solutions. Article 3(2) defines remote data processing as processing at a distance for which the software is designed and developed by the manufacturer, or under its responsibility, and the absence of which would prevent the product performing one of its functions.

So if your reader streams tag events to a vendor-operated backend and depends on that backend to do its job, the backend is inside the regulated product, not a separate service outside the CE boundary. A reader running its logic locally and posting to a customer-owned endpoint sits differently — the split our ReaderSense Edge MDM notes draw between on-reader logic and management plane.

A point integrators should price in: Article 22(1) makes anyone other than the manufacturer, importer or distributor who carries out a substantial modification and makes the product available the manufacturer for CRA purposes, and Article 22(2) applies Articles 13 and 14 to them — for the affected part, or the whole product where the modification affects its cybersecurity overall. Article 3(30) defines that as a post-market change affecting Annex I Part I compliance, or changing the intended purpose assessed against.

Class depends on what the reader is sold for

Annex III, Class I, item 1 covers identity management systems and privileged access management software and hardware, including authentication and access control readers, including biometric readers. An access control reader is named outright. Two further Class I entries reach networked devices: item 10, physical and virtual network interfaces, and item 12, routers, modems for internet connection, and switches.

So the same reader on the same board sits in two places. Counting cartons through a warehouse portal, it is default-category; as the credential reader on a door, it is an important product, Class I. Nothing physical changed — the intended purpose did. Article 13(3) anchors this: the risk assessment must analyse risks “based on the intended purpose and reasonably foreseeable use”. Annex IV, the critical tier, sits higher again, covering hardware devices with security boxes, smart meter gateways and other devices for advanced security purposes including secure cryptoprocessing, and smartcards or similar devices including secure elements.

Declared intended purpose	Annex III position	Route under Article 32
Inventory, logistics, WIP, asset counting	Not listed — default	Any Article 32(1) route, including module A self-assessment
Authentication or access control at a door, turnstile or barrier	Class I, item 1	Article 32(2); today, module B+C or module H
Reader presenting a routing, switching or internet-connection function	Class I, item 10 or 12	Article 32(2); today, module B+C or module H
Security box, smart meter gateway, secure element	Annex IV (critical)	Article 32(4) — certification scheme or the Class II procedures

Put this in front of your supplier if you are specifying readers for door credentials — the question we work through on an RFID access control and attendance system, against a delegate tracking deployment where the read point counts movements rather than granting access.

Conformity routes, and which one applies today

Article 32(1) gives four routes: (a) internal control, module A, in Annex VIII; (b) EU-type examination, module B, then conformity to type on internal production control, module C; (c) full quality assurance, module H; or (d) a European cybersecurity certification scheme under Article 27(9). Module A is self-assessment; the others involve a notified body.

Article 32(2) narrows that menu for Class I. Where the manufacturer “has not applied or has applied only in part harmonised standards, common specifications or European cybersecurity certification schemes at assurance level at least ‘substantial’… or where such… do not exist”, it goes to module B+C or module H.

That last limb turns on the state of the standards rather than on your choices, and the references stand at request stage today: as checked on 3 October 2026, none has been cited in the Official Journal under Regulation (EU) 2024/2847. The limb is therefore satisfied as matters stand, and a Class I reader takes module B+C or module H. The Commission issued standardisation request M/606 covering 41 standards; CEN, CENELEC and ETSI accepted it on 3 April 2025. Presumption of conformity arrives once a reference is cited in the Official Journal, so re-check on the day you rely on this and record the date.

Two things make the notified-body route workable. Annex VII point 5 expects the technical documentation to list standards applied in full or in part and, where not applied, “descriptions of the solutions adopted” — documenting your own solutions is the expected path — and Article 32(6) requires fees reduced proportionately for SMEs.

Three reporting clocks with three different zero points

For an actively exploited vulnerability, Article 14(2) requires an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident, Article 14(4) requires 24 hours, 72 hours with an initial assessment, then a final report within one month after submission of that notification. Two of the four run from a trigger other than awareness.

Deadline	Clause	Clock starts at	Worked example
Early warning	14(2)(a) / 14(4)(a)	Becoming aware	Aware Mon 12 Oct 2026, 09:00 → Tue 13 Oct, 09:00
Notification	14(2)(b) / 14(4)(b)	Becoming aware	→ Thu 15 Oct, 09:00
Final report — vulnerability	14(2)(c)	A corrective or mitigating measure is available	Fix available day 9, Wed 21 Oct → Wed 4 Nov = day 23, not day 14
Final report — severe incident	14(4)(c)	Submission of the 72-hour notification	Filed Thu 15 Oct → Sun 15 Nov = day 34 after awareness

Under Articles 14(1) and 14(3) notification goes simultaneously to the coordinating CSIRT and to ENISA via the Article 16 platform — one submission, two recipients — and Article 14(6) lets that CSIRT request an intermediate status report.

The severity test is broader than it first reads. Article 14(5) treats an incident as severe where it “negatively affects or is capable of negatively affecting” the product’s ability to protect availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or “has led or is capable of leading to” malicious code. A demonstrated capability is enough to start the clock, ahead of any realised harm.

With no EU establishment, your distributor picks your regulator

The default in Article 14(7) is the CSIRT of your main establishment in the Union — the second subparagraph defines that as the Member State where decisions on your products’ cybersecurity are predominantly taken, failing which where you have most employees. With no main establishment, the third subparagraph applies this order:

1. the Member State of the authorised representative acting for you for the highest number of your products;
2. failing that, the importer placing the highest number on the market;
3. failing that, the distributor making the highest number available;
4. failing that, where the highest number of users are located.

Worked scenario: an Indian manufacturer, no EU establishment, no authorised representative. Limb (a) is empty. Importers sit in Germany and the Netherlands; the German one placed more units last year. Limb (b) resolves and the German CSIRT coordinates — a regulator chosen by a volume that can flip year to year.

One stabiliser sits at the bottom: where limb (d) applies, subsequent notifications may go to the same CSIRT first reported to. That continuity attaches to limb (d) alone, so under limbs (a) to (c) the cascade is re-run each time. The clean fix is Article 18(1), appointing an authorised representative by written mandate, which settles the question at limb (a). Note where the mandate stops: Article 18(2) excludes Article 13(1) to (11), 13(12) first subparagraph, and 13(14), so design, risk assessment, vulnerability handling and the technical documentation stay with the manufacturer.

Products already installed are in scope for reporting

Article 69(2): products placed on the market before 11 December 2027 are subject to the Regulation only if, from that date, they undergo a substantial modification. Read alone, that sounds like comprehensive grandfathering.

Article 69(3): “By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.”

Side by side, the second removes the first for reporting. Readers you shipped in 2023 and still running on a customer’s dock are in scope, and have been since 11 September 2026 — reporting applies on its own terms, with no substantial modification needed and no requirement for the product to meet Annex I. Your vulnerability intake therefore has to cover firmware still in the field as well as the current release. Separately, Article 69(1) keeps EU type-examination certificates issued on cybersecurity grounds under other Union legislation valid until 11 June 2028.

What the CRA actually asks of an SBOM

Annex I, Part II, point (1) requires manufacturers to identify and document vulnerabilities and components, “including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”. Top-level dependencies are the floor, not the ceiling. Format is open, though Article 13(24) lets the Commission specify format and elements by implementing act.

Annex VII point 2(b) places the SBOM in the technical documentation alongside the coordinated vulnerability disclosure policy, a reporting contact address, and a description of the secure update distribution solution. Annex VII point 8 says it is provided “further to a reasoned request from a market surveillance authority”; Article 13(25) lets authorities collect SBOMs for a Union-wide dependency assessment by ADCO.

Publishing to customers is left to the manufacturer. Annex II point 9 says that if the manufacturer makes the SBOM available to the user, the user information states where it can be accessed. Draw one up, keep it in the file, hand it over on a reasoned request — and if you are the buyer, make the copy a contract term. It is one of eight Annex I Part II duties, the rest covering remediation, testing, disclosure of fixed vulnerabilities, secure update distribution and free-of-charge dissemination.

Lifecycle numbers you can paste into a tender

Obligation	Clause	The number as drafted
Support period	Art. 13(8), 3rd subpara.	At least five years, or the expected time in use where that is shorter
Availability of each security update	Art. 13(9)	Minimum 10 years after issue, or the rest of the support period, whichever is longer
Technical documentation and EU declaration of conformity	Art. 13(13)	Kept available 10 years from placing on the market, or the support period, whichever is longer
User information and instructions	Art. 13(18)	Same basis, including when provided online
Support end date	Art. 13(19)	Specified at the time of purchase, at least the month and year
Single point of contact	Art. 13(17)	Users choose their preferred means of communication, and the means offered extend beyond automated tools

Two are quietly demanding. Article 13(19) makes the support end date a pre-sale disclosure, so it belongs on the quotation. Article 13(17) asks for a human-reachable channel alongside any automated one. Both are process commitments rather than engineering ones, worth settling at order stage alongside the terms on our RFID manufacturer and exporter page.

Penalties, and the SME derogation as written

Three fine tiers under Article 64, each a cash ceiling or a turnover percentage, whichever is higher. Article 64(2) covers the Annex I requirements and Articles 13 and 14: up to EUR 15 000 000, or for an undertaking 2.5 per cent of total worldwide annual turnover for the preceding financial year. Article 64(3) sets EUR 10 000 000 or 2 per cent for Articles 18 to 23, Article 28, specified paragraphs of Articles 30 to 33 — 30(1) to (4), 31(1) to (4), 32(1), (2) and (3), and 33(5) — plus Articles 39, 41, 47, 49 and 53. Article 64(4) sets EUR 5 000 000 or 1 per cent for incorrect, incomplete or misleading information supplied on request.

Article 64(5)(c) requires regard to the operator’s size, “in particular with regard to microenterprises and small and medium sized-enterprises, including start-ups”. Then Article 64(10): “By way of derogation from paragraphs 3 to 9, the administrative fines referred to in those paragraphs shall not apply to” (a) microenterprises or small enterprises for any failure to meet the deadline in Article 14(2)(a) or 14(4)(a), and (b) any infringement by open-source software stewards.

Observe the cross-reference on the face of the text. The derogation runs from paragraphs 3 to 9; the Article 14 fine sits in paragraph 2. A small manufacturer relying on this relief should take advice on how its Member State transposed Article 64(1), and plan on the 24-hour deadline being enforced. The category is defined rather than self-declared: recital 5 directs that the Annex to Commission Recommendation 2003/361/EC apply in its entirety, including Article 6 on partner and linked enterprises, so a parent or minority investor can consolidate you out of it.

The rule your reader is already under, and the handover

Commission Delegated Regulation (EU) 2022/30 of 29 October 2021 (OJ L 7, 12.1.2022, p. 6) supplements the Radio Equipment Directive 2014/53/EU, activating the essential requirements in Article 3(3), first subparagraph, points (d), (e) and (f) — network harm, personal data and privacy, and fraud — for specified categories of radio equipment. As published it applied from 1 August 2024. Commission Delegated Regulation (EU) 2023/2444 of 20 July 2023 (OJ L, 2023/2444, 27.10.2023) replaced that date: its Article 1 substitutes the second paragraph of Article 3 of 2022/30 with “It shall apply from 1 August 2025.” So 1 August 2025 is the operative date, and it traces to the amending act rather than the original.

Commission Implementing Decision (EU) 2025/138, dated on its face Done at Brussels, 28 January 2025 and published at OJ L, 2025/138, 30.1.2025, amended Implementing Decision (EU) 2022/2191 to add the EN 18031:2024 series: -1 network protection, -2 personal data and privacy, -3 fraud. The references were published with restrictions, notably on clauses 6.2.5.1 and 6.2.5.2 of all three parts.

Commission Delegated Regulation (EU) 2026/339 of 16 February 2026, published at OJ L, 2026/339, 29.4.2026, states at Article 1: “Delegated Regulation (EU) 2022/30 is repealed with effect from 11 December 2027.” Recital 3 explains why — the CRA’s Annex I requirements include all the elements of RED Article 3(3)(d), (e) and (f) — and recital 5 preserves market surveillance of equipment placed on the market between 1 August 2025 and 10 December 2027.

Continuous coverage, a different route. Until 10 December 2027 a radio-equipped reader answers to the RED delegated regulation, where EN 18031 offers a self-declaration path within its restrictions. From 11 December 2027 it answers to the CRA, where an access control reader is Class I and Article 32(2) applies until a harmonised standard is cited.

A pre-incident readiness checklist

A 24-hour clock is met by a process that is already standing when the report lands. Five things belong in place first:

1. Register your Primary Assigned Representative on the ENISA Single Reporting Platform now. One primary representative is permitted per manufacturer, who can then invite up to 20 secondary representatives; manufacturer association is verified in parallel with reporting, and an account set up in advance means the 24-hour clock is spent drafting rather than onboarding.
2. Answer the Article 14(7) cascade in advance and write it down, with the volumes supporting it and a date to re-check. If it is unstable, an authorised representative under Article 18(1) fixes it at limb (a).
3. Pre-draft the 24-hour early warning fields. Articles 14(2)(a) and 14(4)(a) ask for the Member States where you are aware the product has been made available — a distribution question, answerable today.
4. Assign the Article 14(8) user-notification duty to a named owner. The manufacturer informs impacted users of the vulnerability or incident and any mitigations, “where appropriate in a structured, machine-readable format”. Where that is not done in a timely manner, the notified CSIRTs may inform users instead.
5. Map Annex I Part I point (2) onto your firmware. Its thirteen sub-points apply on the basis of the risk assessment and where applicable, from no known exploitable vulnerabilities (a) and secure-by-default with reset (b), through automatic updates with opt-out (c), access protection (d), encryption (e) and integrity reporting (f), to security logging with opt-out (l) and secure deletion (m).

Underneath all five sits one decision: your declared intended purpose. It drives Annex III classification, the Article 32 route and the Article 13(3) risk assessment. Decide it once, state it consistently across the datasheet, the declaration of conformity and the Annex II user information, and keep the reasoning in the technical file.

Frequently asked questions

Does the Cyber Resilience Act apply to an RFID reader?

Yes. Article 2 sets the scope and Article 3(1) defines a product with digital elements as a software or hardware product and its remote data processing solutions, which a networked reader satisfies. Article 3(2) also pulls in the manufacturer’s own remote data processing where the product could not perform one of its functions without it. Full application is 11 December 2027, and the Article 14 reporting duties have applied since 11 September 2026.

Is an access control reader an important product under the CRA?

Annex III, Class I, item 1 names authentication and access control readers, including biometric readers. So a reader placed on the market for door authentication is an important product in Class I, while the same hardware sold for inventory counting sits in the default category. Article 13(3) ties the assessment to the intended purpose and reasonably foreseeable use, so the declared purpose decides it.

When do CRA obligations start applying?

Article 71(2): the Regulation applies from 11 December 2027, Article 14 from 11 September 2026, and Chapter IV (Articles 35 to 51) from 11 June 2026. Entry into force follows the Article 71(1) formula — the twentieth day after publication in the Official Journal on 20.11.2024, which is 10 December 2024.

Which CSIRT does a non-EU manufacturer report to?

Article 14(7). With no main establishment in the Union, the cascade runs in order: the Member State of the authorised representative acting for the highest number of your products; then the importer placing the highest number on the market; then the distributor making the highest number available; then where the highest number of users are located. Where that last limb applies, subsequent notifications may go to the same CSIRT first reported to.

Do products already sold before December 2027 need CRA reporting?

Yes. Article 69(2) would exempt products placed on the market before 11 December 2027 unless they undergo a substantial modification — but Article 69(3) derogates from it and applies the Article 14 obligations to all in-scope products placed on the market before that date. Installed readers are therefore in scope for reporting on their own terms, with no modification required.

Does the CRA require publishing an SBOM?

Drawing one up is required; publishing it is left to the manufacturer. Annex I, Part II, point (1) requires a software bill of materials in a commonly used, machine-readable format covering at the very least the top-level dependencies. Annex VII point 8 has it provided further to a reasoned request from a market surveillance authority, and Annex II point 9 leaves disclosure to users to the manufacturer’s choice.

How long must a manufacturer support a product under the CRA?

Article 13(8) sets the support period at at least five years, or the expected time in use where that is shorter. Article 13(9) keeps each security update available for a minimum of 10 years after issue, or the remainder of the support period, whichever is longer. Article 13(19) requires the support end date, including at least the month and the year, at the time of purchase.

What date applies to the RED cybersecurity requirements?

1 August 2025. Delegated Regulation (EU) 2022/30 as published applied from 1 August 2024; Article 1 of Commission Delegated Regulation (EU) 2023/2444 of 20 July 2023 replaced the second paragraph of its Article 3 with “It shall apply from 1 August 2025.” Delegated Regulation (EU) 2026/339 then repeals 2022/30 with effect from 11 December 2027, when the CRA takes over.

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L, 2024/2847, 20.11.2024
• European Commission — CRA reporting obligations, applicable from 11 September 2026
• ENISA — CRA Single Reporting Platform
• ENISA — Single Reporting Platform FAQ (one Primary AR, up to 20 Secondary ARs, verification in parallel with reporting)
• European Commission — CRA standardisation, request M/606 and its 41 standards
• CEN-CENELEC — ESOs accepted standardisation request M/606 on 3 April 2025
• CRA state of play — no harmonised standard yet cited in the Official Journal
• Commission Delegated Regulation (EU) 2022/30 of 29 October 2021, OJ L 7, 12.1.2022, p. 6
• Commission Delegated Regulation (EU) 2023/2444 of 20 July 2023, OJ L, 2023/2444, 27.10.2023 — Article 1: 2022/30 "shall apply from 1 August 2025"
• Commission Implementing Decision (EU) 2025/138 of 28 January 2025 — EN 18031 cited with restrictions
• Commission Delegated Regulation (EU) 2026/339 of 16 February 2026 repealing 2022/30 from 11 December 2027
• Draft repealing act as adopted: C(2026) 778 final, Brussels, 16.2.2026