The Cyber Resilience Act (CRA) requires the manufacturer of a product with digital elements to set a security support period that reflects how long the product is expected to be in use (CRA, Article 13(8)).
Our reading: the decision is three things written into the technical file: how long a machine within the CRA's scope is expected to be in use, which end date each unit carries, and how vulnerabilities in its components will be handled until then.
The Regulation "shall apply from 11 December 2027"; Article 14, on reporting, has applied since 11 September 2026 (CRA, Article 71(2)). This article is not legal advice, and a specific product needs qualified review. Sources were retrieved on 7 October 2026.
How long must the CRA support period be for a machine?
It must reflect how long the machine is expected to be in use. It must be at least five years, unless the machine is expected to be in use for less than five years, in which case it corresponds to the expected use time. Article 13(8) of the Cyber Resilience Act states criteria and that general minimum; it gives no number of years for machinery. The manufacturer determines the period and records the information it took into account in the technical documentation.
These rules are in Article 13(8), whose three matters to weigh "in particular" and four that a manufacturer "may also take into account" are rows B to E of the decision record below; row G is its proportionality requirement (CRA, Article 13(8)).
When does the support period start for each unit?
Article 13(8) of the Cyber Resilience Act does not expressly state the first day of the support period. Examples in the Commission's draft guidance and in its services' FAQ count the period from placing on the market. The Commission's Blue Guide, which is guidance and not law, says placing on the market refers to each individual product, not to a type of product. Our reading: the period therefore runs for each unit from its own placing on the market, not from the model's launch and not from an order accepted before the unit is finished.
Article 13(8) applies the duty "when placing a product with digital elements on the market, and for the support period" (CRA, Article 13(8)). The examples are Example 52 (Guidance, Example 52) and the FAQ's batch example (FAQ, entry 4.5.3). For hardware such as machinery, the draft guidance points to the Blue Guide (Guidance, paragraph 12). Three of its tests matter here:
- Each unit, not the model. Placing on the market "refers to each individual product, not to a type of product, and whether it was manufactured as an individual unit or in series" (Blue Guide, section 2.3).
- Built to order. Placing "requires that the manufacturing stage has been completed"; an offer or agreement made before manufacture is finished "cannot be considered as placing on the market" (Blue Guide, section 2.3).
- Group sales companies. In one example, a product sent to the manufacturer's own distribution branch is placed that day, "Even if the distributor belongs to the manufacturer" (Blue Guide, section 2.12, example 3).
Our reading: because placing "does not require the physical handover of the product" (Blue Guide, section 2.3), the date may fall before delivery or commissioning, and a unit waiting in a distributor's warehouse uses up supported time.
Fixed model end date or rolling per-unit period
A machine sold over several years raises a choice that Article 13(8) does not name: a period of the same length for each unit, counted from its own placing on the market, or one calendar end date for every unit of the model (CRA, Article 13(8)). Under either form, the buyer must be shown an end date, including at least the month and year; a duration alone does not supply the required date (CRA, Article 13(19)).
| Our reading of the consequence | Rolling: N years from each unit's placing | Fixed: one month and year for all units |
|---|---|---|
| Examples in the texts | Example 52 (Guidance, Example 52) and the FAQ's batch example (FAQ, entry 4.5.3). Example 52 concerns a smartphone; the FAQ example does not identify a particular hardware product type | Not described in those two examples |
| Date shown to buyers | Differs by batch or serial number | The same for every unit. Where the date is set so that the last unit placed receives the full period, earlier units get more than the period, by up to the interval between the first and last placing dates; where it is set from an earlier unit, later units get less (see the example below) |
Our reading: a fixed end date constrains the latest placing date for units requiring the chosen period. Production and inventory plans must be reconciled with that date.
Are security updates free of charge for the whole support period?
Generally yes, for the security updates the CRA requires, unless a manufacturer and business user agree otherwise for a tailor-made product. For a software product, Article 13(10) permits remediation only for the last substantially modified version placed on the market when earlier users can obtain it free of charge without additional costs to adjust their hardware and software environment. The draft guidance says optional continued fixes for those earlier versions may then be offered on a paid basis.
The rule is point (8) of the vulnerability handling requirements (CRA, Annex I, Part II, point (8)), which Article 13(8) applies for the support period (CRA, Article 13(8)). The software condition is Article 13(10) (CRA, Article 13(10)); the paid-basis statement is footnote 19 of the draft guidance (Guidance, footnote 19). Our reading: budget for the generally required free dissemination of security updates.
Supply agreements
The integration duties sit on the machine builder. It "shall exercise due diligence when integrating components sourced from third parties" (CRA, Article 13(5)).
The FAQ says the CRA "does not require manufacturers to provide a patch for all vulnerabilities that are discovered during a product’s support period", and that risk-based remedies still need to be "put in place without delay" (FAQ, entry 4.3.1). Where a vulnerability in a component whose own support has ended cannot be adequately mitigated, the FAQ says the manufacturer "is required to remediate the vulnerability via other means, for example by switching out the integrated component or developing a patch autonomously" (FAQ, entry 4.3.7).
Our reading, a proposed implementation and not a requirement of the passages quoted: use the supply agreement to obtain the supplier's support end date, a security contact, the component's security documents and, for components outside the CRA, a commitment to fix or permission for the builder to fix.
Can the support period be shorter than the machine's expected life?
Article 13(8) of the Cyber Resilience Act requires the support period to reflect the length of time the product is expected to be in use, and the matters taken into account to be considered in a manner that ensures proportionality. The Commission services' FAQ, which is not authoritative, says five years is not sufficient where a product is reasonably expected to be in use for longer than five years. Our reading: documenting the Article 13(8) factors is necessary, but does not by itself establish that a period shorter than expected use complies. Any shorter period needs product-specific legal assessment; Article 13(8) and FAQ entry 4.5.2 provide no numerical safe harbour.
The passages are Article 13(8) (CRA, Article 13(8)) and FAQ entry 4.5.2 (FAQ, entry 4.5.2). The draft guidance's machinery example sets the period "to align with that expected use time" (Guidance, Example 55). The FAQ says manufacturers are "not expected to simply set support periods that correspond to the expected use time (unless the expected use time is less than five years" (FAQ, entry 4.5.1). Our reading: the two can be read as pointing in different directions, or the FAQ may mean only that expected use is not the sole input.
Options and decision record
Record the product boundary for qualified assessment. Do not treat separate controller or back-end periods as an established way to shorten the machine's support: Article 13(8) covers vulnerabilities of the product, including its components (CRA, Article 13(8)).
Rows marked "proposed" are our fields, not requirements of the passages quoted.
| Element | Basis | Our reading: evidence to file |
|---|---|---|
| A. Product boundary and owner (proposed) | Vulnerabilities "of that product, including its components" (CRA, Article 13(8)) | Machine, controller, software and remote services covered; who owns the compliance conclusion |
| B. Expected-use evidence | The period "reflects" expected use, weighing reasonable user expectations and the nature of the product, including its intended purpose (CRA, Article 13(8)); Example 55 uses "physical durability of the machinery hardware and expected wear and tear" (Guidance, Example 55) | Design life, customer requirements and service-life statements, each with a dated source; unresolved gaps |
| C. Union law determining lifetime | The Machinery Regulation defines "lifetime" as lasting "until the moment that it is discarded" (Machinery Regulation, Article 3, point (34)). Whether that counts under this limb is unresolved here | Which product law was considered, and how it was read |
| D. Similar products; ADCO and Commission guidance | Optional (CRA, Article 13(8)); ADCO, the dedicated administrative cooperation group, is to publish statistics "including average support periods" (CRA, Article 52(16)) | Published end dates of comparable products, with the pages searched; guidance and FAQ versions relied on, with dates |
| E. Operating environment and third-party core components | Optional (CRA, Article 13(8)) | Horizon of each release and each supplier's stated end date (table below) |
| F. Coverage gap and remedy (proposed) | Risk-dependent remedies (FAQ, entry 4.3.1); the FAQ's "other means" (FAQ, entry 4.3.7) | Exact component and version, supported functionality, supplier commitment, mitigation, patching, replacement or migration route, validation work, accountable owner |
| G. Proportionality | The matters "shall be considered in a manner that ensures proportionality" (CRA, Article 13(8)) | Any gap between row B and the declared date, with the legal assessment of it |
| H. Minimum | "at least five years", or the expected use time where that is less than five years (CRA, Article 13(8)) | A check on the last unit placed, not the first |
| I. End date and record | Month and year at the time of purchase (CRA, Article 13(19)) | The date as shown, rolling or fixed; this record, dated, with a named owner |
| J. Commercial decision (proposed) | None in the passages quoted | Quotations or estimates still needed, budget owner, approval condition |
Row E: published horizons, retrieved 7 October 2026
| Item | Publisher's statement | Limit stated by the publisher |
|---|---|---|
| Linux kernel, Civil Infrastructure Platform (CIP) | 5.10 until 2031, 6.1 until 2033, 6.12 until 2035 (6 August 2026) (CIP blog, 6 August 2026) | The series "aim for at least 10 years of support" (CIP blog, 6 August 2026), on "a reduced set of kernel subsystems and features" (13 January 2025) (CIP blog, 13 January 2025) |
| OpenSSL long-term releases | 3.5 "will be supported until 2030-04-08 (LTS)" (last modified 07 May 2026) (OpenSSL Project) | "During the final year of support, we do not commit to anything other than security fixes" (OpenSSL Project) |
| Controller software, Bosch Rexroth ctrlX OS | Of "LTS releases": "They are maintained with security updates over 5 years beginning from respective general release" (community how-to; page shows 08/06/2024) (Bosch Rexroth) | Early adopter releases "are supported for several months and do not receive bugfix or updates after that period" (Bosch Rexroth) |
Our reading: a machine using these particular versions may need vulnerability handling beyond their publishers' stated support horizons. Row F should record the evidence for a feasible mitigation, patching, replacement or migration route; support expiry alone does not establish that migration is required (FAQ, entry 4.3.1; FAQ, entry 4.3.7).
Illustrative example with dates
Illustrative assumptions: the first unit is placed on the market in January 2028 and the last in December 2030; each unit is expected to be in use for 20 years, on a CIP 6.12 kernel and OpenSSL 3.5; the manufacturer issues a security update in December 2050.
| Timeline | Point | Date | Working |
|---|---|---|---|
| Support | Rolling period: first unit ends | January 2048 | January 2028 + 20 years |
| Support | Rolling period: last unit ends | December 2050 | December 2030 + 20 years |
| Support | Fixed date giving every unit 20 years | December 2050 | First unit: January 2028 to December 2050 = 22 years 11 months |
| Support | Fixed date taken from the first unit | January 2048 | Last unit needs December 2050; January 2048 to December 2050 = 2 years 11 months short |
| Components | OpenSSL 3.5 support ends | April 2030 | Before the last unit is placed (OpenSSL Project) |
| Components | CIP 6.12 kernel support ends | 2035 | The last unit's support runs beyond the stated 2035 horizon; the source gives no month, so the exact gap is not established (CIP blog, 6 August 2026) |
| Update availability | The assumed December 2050 update remains available | At least December 2060 | Each security update made available during the support period "remains available after it has been issued for a minimum of 10 years or for the remainder of the support period, whichever is longer"; December 2050 + 10 years = December 2060; the remainder of the last unit's support period is under one month, so 10 years is the longer (CRA, Article 13(9)) |
| Reporting | Article 14 duties | Article 14 has applied since 11 September 2026, before the first assumed placing (CRA, Article 71(2)) | Draft guidance: the reporting obligations "continue to apply after a product with digital elements is no longer supported" (Guidance, paragraph 210); Article 14 does not mention the support period (CRA, Article 14) |
Our reading: these are four timelines, not one. Whether a fixed date of January 2048, short of the last unit's assumed expected use, complies is not established by the passages quoted and needs product-specific legal assessment.
A first step that changes nothing on the machine
Our reading: start with a desk exercise on one product line. Fill in the decision record from documents already held, add the planned first and last months of placing on the market, and work out the end date under both forms. The rows left without evidence are the output.
An open point
- Components that cannot be replaced or patched. What follows when neither of the FAQ's two examples of "other means" is feasible (FAQ, entry 4.3.7). Whether Article 13(21), on corrective measures, withdrawal or recall, then applies is an escalation question for qualified assessment (CRA, Article 13(21)).
The reference notes list further open points.
Reference notes
The Regulation defines the support period as "the period during which a manufacturer is required to ensure that vulnerabilities of a product with digital elements are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I" (CRA, Article 3(20)).
The five-year minimum: further passages
The draft guidance says a support period of five years "is therefore not to be considered as the default for all products with digital elements" (Guidance, paragraph 126). A recital says that where a product is reasonably expected to be in use for longer than five years manufacturers "should accordingly ensure longer support periods", and that products for industrial settings "are often in use for significantly longer periods of time" (CRA, recital 60).
A recital is not an article, and neither the FAQ nor the draft guidance is law. The guidance says it "is not binding for economic operators" (Guidance, paragraph 8); the FAQ says its views "are not authoritative" (FAQ, front matter).
Placing on the market: further passages
Placing on the market "means the first making available of a product with digital elements on the Union market" (CRA, Article 3(21)). The draft guidance carries the Blue Guide's per-unit concept into the CRA (Guidance, paragraph 11).
Later sales in the chain are not a new placing: "Any subsequent operation, for instance, from a distributor to distributor or from a distributor to an end-user is defined as making available" (Blue Guide, section 2.3). In the Blue Guide's machine example, a machine ordered on 1 April 2019 from a manufacturer outside the EU and shipped on 1 June 2019 is placed on the market on 1 June 2019, when it "is already manufactured and ready to be shipped" (Blue Guide, section 2.12, example 5).
The draft guidance treats copies of the same software as "placed on the market at the same time" (Guidance, paragraph 14), and says that this "applies exclusively insofar as the product with digital elements is standalone software" (Guidance, paragraph 16).
Products must "bear a type, batch or serial number or other element allowing their identification, or, where that is not possible, that that information is provided on their packaging or in a document accompanying the product with digital elements" (CRA, Article 13(15)). Our reading: a per-unit end date can be keyed to that identifier. Example 52 has "a support period of X years from the date of placement on the market" (Guidance, Example 52). In the FAQ's example, units placed in January 2028 with a five-year period are supported "until January 2033", and a distributor "can continue to make those units available even after January 2033" (FAQ, entry 4.5.3). Technical documentation is kept "for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer" (CRA, Article 13(13)).
Events that change the period, and events that do not
For a substantially modified product, the draft guidance asks "whether the substantial modification affects the factors that originally determined that product’s expected use time and, therefore, the original support period" (Guidance, paragraph 133).
| Event | What the sources say |
|---|---|
| Substantial modification that leaves those factors unchanged | The period "should align with the remaining expected use time of the product as originally placed on the market" (Guidance, paragraph 134) |
| The manufacturer of a machinery product "rearchitects the cloud back-end" in a manner that qualifies as a substantial modification "but does not alter the nature of that product or affect user expectations" (Example 55) | The period "aligns with the remaining expected use time as originally determined" (Guidance, Example 55) |
| The manufacturer of a programmable logic controller (PLC) replaces its "embedded computing platform" with components "designed for a significantly longer operational lifetime" (Example 56) | The criteria "indicate a longer expected use time, and the manufacturer recalculates the support period for that specific PLC accordingly" (Guidance, Example 56) |
| After a PLC's CPU fails, a replacement CPU or a complete replacement PLC that "can be considered identical" is supplied "as a spare part" for a clearly identified automation system (Example 39) | The replacement "falls within the scope of the exemption in Article 2(6)" (Guidance, Example 39). That Article covers spare parts "made available on the market to replace identical components" and "manufactured according to the same specifications" (CRA, Article 2(6)) |
| Later, substantially modified version of a software product | The manufacturer may meet point (2) of the vulnerability handling requirements "only for the version that it has last placed on the market", provided earlier users have access to it "free of charge" and "do not incur additional costs to adjust the hardware and software environment" (CRA, Article 13(10)) |
The draft guidance says a manufacturer relying on Article 13(10) "remains subject to the other vulnerability-handling requirements of Part II of Annex I, as well as to the reporting obligations of Article 14" (Guidance, paragraph 131).
Units covered, by date of placing on the market
| Units | Support-period duty | Reporting duty |
|---|---|---|
| Placed on the market before 11 December 2027 | Subject to the requirements "only if, from that date, those products are subject to a substantial modification" (CRA, Article 69(2)). The draft guidance says that for a product placed on the market before 11 December 2027 the manufacturer "is not required to comply with the vulnerability handling obligations set out in Part II of Annex I" (Guidance, paragraph 210); that paragraph does not restate the substantial-modification condition of Article 69(2) | Article 14 "shall apply to all products with digital elements" in scope that were placed before that date (CRA, Article 69(3)) |
| Units of an earlier design placed from 11 December 2027 | In scope; the draft guidance says compliance "does not necessarily require that those units of the product with digital elements be redesigned" (Guidance, paragraph 33) | Applies (CRA, Article 71(2)) |
| Units of a new design placed from 11 December 2027 | A period determined under Article 13(8), with the end date shown at the time of purchase (CRA, Article 13(8); CRA, Article 13(19)) | Applies (CRA, Article 71(2)) |
End-of-support notice
"Where technically feasible in light of the nature of the product with digital elements, manufacturers shall display a notification to users informing them that their product with digital elements has reached the end of its support period" (CRA, Article 13(19)).
Component suppliers, tailor-made products and source code
The draft guidance says evidence of due diligence "may consist of documentation obtained from the component manufacturer, such as technical specifications, security documentation or relevant conformity or assurance documentation" (Guidance, paragraph 171). For a component never placed on the market, or placed before the CRA applies, the FAQ says its developer "is not subject to the CRA vulnerability handling obligations", and adds: "The integrating manufacturer is nonetheless required to ensure that its product complies in its entirety with the vulnerability handling requirements" (FAQ, entry 4.3.6).
Recital 64 says manufacturers should only be able to deviate for tailor-made products "fitted to a particular purpose for a particular business user and where both the manufacturer and the user have explicitly agreed to a different set of contractual terms" (CRA, recital 64). The FAQ says manufacturers "may deviate from two essential requirements", secure-by-default configuration and free-of-charge security updates, says a product is not tailor-made when it undergoes "minor customisations before being sold to a customer, without specific sets of contractual terms or arrangements", and names no machine among its examples (FAQ, entry 4.2.5). Our reading: the length of the support period is not one of the two requirements, and whether an engineered-to-order machine qualifies is unresolved here.
A recital says manufacturers "should consider releasing the source code" at the end of support to "other undertakings which commit to extending the provision of vulnerability handling services or to the public" (CRA, recital 61).
Machinery Regulation passages
The Machinery Regulation applies from 20 January 2027, with earlier dates for the Articles listed in its Article 54 (Machinery Regulation, Article 54); a corrigendum reads "20 January 2027" in place of "14 January 2027" (Machinery Regulation corrigendum, item 10). On penalties, Article 50(1), which as corrected applies from 20 October 2026 (Machinery Regulation corrigendum, item 12), says: "Member States shall lay down the rules on penalties applicable to infringements by economic operators of this Regulation" (Machinery Regulation, Article 50(1)).
Recital 53 of the CRA says compliance with its requirements "could facilitate the compliance" with Machinery Regulation requirements, in particular sections 1.1.9 and 1.2.1 of Annex III, and adds: "Such synergies have to be demonstrated by the manufacturer" (CRA, recital 53). The FAQ says compliance with the cybersecurity requirements of only one of the two Regulations "cannot be automatically considered to also fully satisfy those of the other Regulation" (FAQ, entry 2.4.2).
The Machinery Regulation has its own five-year figure: the tracing log of "the versions of safety software uploaded after the machinery or related product has been placed on the market or put into service is enabled for five years after such upload" (Machinery Regulation, Annex III, section 1.2.1(f)). Our reading: that log period and the CRA minimum are separate duties.
Status of the Commission guidance
As served on 7 October 2026, the Communication of 27 July 2026 says the guidance "will be formally adopted by the Commission at a later date, when all language versions are available", and "It is only from that moment that it will apply" (Communication C(2026) 5252). FAQ version 1.4, dated 04/09/2026 in its version table, says "The Commission has also adopted guidance pursuant to Article 26 of the CRA" (FAQ, front matter). These materials do not resolve its formal status.
Paragraph and example numbers here are those of the draft. An authoritative interpretation of the CRA "may only be given by the Court of Justice of the European Union" (Guidance, paragraph 8).
Supervision and penalties
Market surveillance authorities "shall monitor how manufacturers have applied the criteria referred to in Article 13(8)" (CRA, Article 52(16)). The Commission "may adopt delegated acts" specifying "the minimum support period for specific product categories where the market surveillance data suggests inadequate support periods" (CRA, Article 13(8)). Whether any has been adopted is not established here.
Non-compliance with Annex I and with Articles 13 and 14 "shall be subject to administrative fines of up to EUR 15 000 000 or, if the offender is an undertaking, up to 2,5 %" of total worldwide annual turnover for the preceding financial year, "whichever is higher" (CRA, Article 64(2)). That is a ceiling. Article 64(10), as corrected, derogates from paragraphs 2 to 9 in the cases quoted below (CRA corrigendum).
Fines may be imposed, "depending on the circumstances of each individual case, in addition to any other corrective or restrictive measures applied by the market surveillance authorities for the same infringement" (CRA, Article 64(9)).
As corrected on 2 July 2025, Article 64(10) opens "By way of derogation from paragraphs 2 to 9" (CRA corrigendum). For manufacturers it covers microenterprises and small enterprises only "with regard to any failure to meet the deadline referred to in Article 14(2), point (a), or Article 14(4), point (a)"; its point (b) covers "any infringement of this Regulation by open-source software stewards" (CRA, Article 64(10)).
Further open points
- Embedded software. Article 13(10) is written for "a software product" (CRA, Article 13(10)); guidance Example 52, which applies it, concerns a smartphone (Guidance, Example 52).
- One date for the model. Article 13(8) and Article 13(19) do not say whether a single end date for all units of a model is acceptable, or how batches are to be marked (CRA, Article 13(8); CRA, Article 13(19)).
- The placing event for a given builder. Blue Guide sections 2.3 and 2.12 give general tests and hypothetical examples. Which event counts for an ex-works handover or for commissioning on site is unresolved here; the test is "an offer or an agreement (written or verbal) between two or more legal or natural persons for the transfer of ownership, possession or any other property right" (Blue Guide, section 2.3).
- Supplier duties toward the builder. Article 13(6) runs from the builder to the supplier (CRA, Article 13(6)). After becoming aware of an actively exploited vulnerability or a severe incident having an impact on the product's security, a manufacturer "shall inform the impacted users of the product with digital elements, and where appropriate all users" (CRA, Article 14(8)). It must also, "once a security update has been made available, share and publicly disclose information about fixed vulnerabilities"; "in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch" (CRA, Annex I, Part II, point (4)). Whether an integrating builder is a user for these purposes is unresolved here.
- Escalation where a vulnerability cannot be handled. From the placing on the market and for the support period, manufacturers who know or have reason to believe that the product or their processes are not in conformity with the essential cybersecurity requirements "shall immediately take the corrective measures necessary to bring that product with digital elements or the manufacturer’s processes into conformity, or to withdraw or recall the product, as appropriate" (CRA, Article 13(21)). Whether a component vulnerability that cannot be remediated engages that paragraph is a question for qualified assessment, unresolved here.
- Paid maintenance after the end date. For Article 13(10), the draft guidance says "additional costs" does not encompass "reasonable operational effort that is inherent to applying software updates or maintaining a secure operating environment, such as personnel time, routine testing, configuration adjustments or upgrades of underlying software dependencies that are necessary to address end-of-life components or known security vulnerabilities"; it refers to burdens beyond that, "such as mandatory purchases of new hardware, infrastructure replacement or fundamental changes to the operating environment" (Guidance, paragraph 130). Footnote 19 says that, where users can upgrade to the latest version without additional costs, manufacturers "may nevertheless choose to continue addressing and remediating vulnerabilities in earlier versions of that software, including on a paid basis or under other commercial arrangements". Footnote 19 concerns earlier software versions. It does not establish the terms for maintenance after the product's support period (Guidance, footnote 19).
- National penalty rules. Member States lay down the rules on penalties (CRA, Article 64(1)); none is covered here.
- ADCO. ADCO is to "provide guidance that includes indicative support periods for categories of products with digital elements" (CRA, Article 52(16)). Whether it has done so is not established here.
Source boundary
The CRA is quoted from the Official Journal text of 20 November 2024, with Article 64(10) read as corrected. Three corrigenda have an English version and were read; four others have none and were not read. Regulation (EU) 2025/327 replaces Article 13(4) and Article 31(3) of the CRA, inserts Article 32(5a), and "shall apply from 26 March 2027" (Regulation (EU) 2025/327, Articles 104 and 105); none of those paragraphs is quoted here. The Machinery Regulation is quoted from the Official Journal text of 29 June 2023, with its application dates as corrected. Regulations (EU) 2024/2748 and (EU) 2026/1744 amend it; the provisions quoted here were compared with the consolidated version of 27 July 2026, which is a documentation tool without legal effect, and are unchanged there. The guidance, the FAQ and the Blue Guide are non-binding. Project and vendor statements remain their publishers' own. Sentences marked "Our reading" are Hyperion's interpretation, not law. This article is not an account of a client engagement.
Method and AI use
AI agents researched and drafted this article from the public sources listed. Separate AI agents checked its statements against the cited sources; passages added in the final revision were checked against saved copies of those sources. An earlier edition was challenged by a second AI model and this edition incorporates corrections from that review; the final revision has not been re-read in full by a second model. No independent legal review.
Related service: Product Decision Review.
