The five-year service contract and the twenty-five-year support commitment
The project's commercial team has finalised the long-term service agreement with the turbine manufacturer. Five years from commercial operation date, renewable thereafter, with availability guarantees, response times, parts inventory commitments, and an agreed schedule for routine maintenance. The contract runs to fifty pages. Both parties' legal teams have reviewed it. It is signed.
The asset owner's security architect is reading the contract for a different purpose. She is mapping it against the Cyber Resilience Act requirement that the manufacturer publicly declare the support period for the product — the window during which security patches will be provided free of charge, through the patch delivery contract earlier in this series. She finds the declared support period stated in the manufacturer's product documentation, separately from the service agreement. The product support period is fifteen years from initial release.
The wind farm is being commissioned in 2027. The turbines being installed today are based on a product line first released in 2022. The declared support period therefore ends in 2037 — ten years into a twenty-five-year asset life. The long-term service agreement covers years one to five of that life, renewable for additional terms. The lender's term sheet requires the asset to remain supportable for the full operational lifetime.
Three timelines, none aligned, none addressing the same question. The service agreement protects availability and ongoing maintenance. The product support period protects security patching. The asset's operational life is longer than both. The architecture for closing the gaps is the subject of this article, because none of the timelines closes them alone.
The principle is the distinction between the manufacturer's two commitments. The service agreement is a commercial arrangement — what the manufacturer will do for the asset owner, on what terms, for what price, over what duration. The product support period is a regulatory obligation — what the manufacturer must do for the product, regardless of any specific commercial relationship, under the Cyber Resilience Act and the equivalent regimes emerging in other jurisdictions. The two operate on different timescales, are governed by different frameworks, and impose different obligations on the manufacturer. They are not substitutes, and treating either as if it covered the other's scope is a category error the asset owner cannot afford to make.
The two commitments and what each covers
The long-term service agreement is the well-established commercial instrument. Five years from commercial operation date is the typical initial term, extendable by mutual agreement on three- to five-year cycles thereafter. The agreement covers availability guarantees (typically expressed as annual capacity factor or equivalent), mean time to recover for various fault categories, response time commitments for technical engagement, parts inventory and replenishment obligations, scheduled and unscheduled maintenance, performance warranties, and the commercial terms — fixed fee, variable element, indexation, payment schedule — that match the work to revenue.
The agreement is bilateral. It can be renegotiated at renewal, transferred under defined conditions, terminated for cause, novated as part of corporate transactions on either side. The pricing reflects the manufacturer's expected cost of providing the service over the agreed term, with margin. Both parties have negotiating positions; the result is a contract.
The product support period is something quite different. CRA Article 13, read alongside the implementing acts as they are issued through 2026 and 2027, requires the manufacturer to publicly declare the support period for the product — the window during which security updates will be provided. The declared period must reflect the expected lifetime and use of the product class. For industrial equipment with a designed operational lifetime measured in decades, the support period must reflect that lifetime; declaring a five-year support window for a turbine controller designed to operate for thirty years is not a defensible position under the regulation's intent, even if it is technically a declaration.
The product support period is unilateral. The manufacturer commits to the period publicly, at the point of placing the product on the EU market. The commitment runs to all customers of the product, not specifically to any one of them. It cannot be renegotiated downward at the asset owner's request; it does not require any particular commercial relationship to continue; and it imposes the obligation to provide free security updates regardless of whether the asset owner has an active service agreement with the manufacturer.
The two commitments are independent in design, related in practice, and frequently confused in early conversations. The CRA does not require the manufacturer to provide field service free of charge for thirty years — the service agreement is the right place to address field service. The CRA does require the manufacturer to provide security patches for the declared support period, regardless of whether a service agreement is in place. The two work together when both are operating; they diverge when one is not.
What the CRA's declared support period actually requires
The declared support period is the manufacturer's public commitment, stated at the time the product is placed on the EU market, regarding the duration of free security update provision. The Cyber Resilience Act does not specify a minimum period in absolute terms; it specifies that the period must be appropriate to the product's expected use and lifetime.
For consumer products with short use cycles, support periods of a few years may be adequate. For industrial equipment, the Commission's evident expectation — reflected in the implementing acts and in guidance from ENISA — is that the support period align with the operational lifetime of the equipment in its intended deployment context. An industrial controller designed for twenty-five-year deployment will be expected to declare a support period commensurate with that lifetime.
The obligations within the declared support period are specific. Security updates must be provided free of charge. They must be made available without undue delay following the manufacturer's awareness of an actively exploited vulnerability — the 24/72/14-hour cadence from CRA Article 14 applies regardless of whether any specific customer has an active service agreement. The patches must be delivered through the structured contract described earlier in this series — signed artefacts, release documentation, SBOM diff, rollback procedure — not as silent updates or as customer-specific deliveries.
What the support period does not include is feature updates, performance improvements, or non-security maintenance. Those remain commercial offerings, typically delivered through the service agreement. The line between security and non-security work is sometimes contested in practice — a firmware update may include both — but the principle is that the security component is free within the support period and the feature component is whatever the commercial arrangement specifies.
A particular operational consequence worth noting. The CRA's support obligation applies to the deployed product version, not only to the current product line. A turbine controller released in 2022 and deployed in 2027 is subject to a fifteen-year support obligation calculated from its original release date, regardless of whether the manufacturer's current product offering has moved on to a newer model. This matters for industrial equipment because deployment cycles are long: a controller installed today may be based on a product line several years old by the time it enters service.
What happens when the service agreement is not renewed
The scenarios in which the two timelines diverge are operationally important.
The service agreement reaches the end of its initial term and is not renewed. The asset owner may have negotiated for renewal at unacceptable commercial terms; may have decided to engage a different service provider for cost or quality reasons; may have moved to in-house operations and maintenance for the equipment. The product support period continues regardless. Patches still arrive through the patch delivery contract, free of charge, on the manufacturer's release cadence. What changes is the deployment capability — the asset owner's own team, the new service provider, or a third-party operations and maintenance contractor performs the field work.
The service agreement is renewed under a different service provider. Independent operations and maintenance companies — Vestas Multibrand Services, GE Vernova Services, Siemens Gamesa Services, but also independent providers like UpWind Solutions, Deutsche Windtechnik for cross-OEM work in wind, and several others across solar and battery — increasingly service multiple manufacturers' equipment under common contracts. The original manufacturer's support obligation for security patches continues; the operational service relationship transfers. This pattern is becoming more common as renewable energy projects mature and asset owners optimise their operations and maintenance economics across mixed fleets.
The manufacturer is acquired by another company. The original entity's CRA support obligation transfers to the acquiring entity as a matter of regulation. In practice, the integration of product lines, engineering organisations and patch infrastructure under the new corporate structure may take months or years; the asset owner's contractual position should anticipate this, with commitments that survive corporate transactions and remedies that activate if the acquiring entity fails to maintain the support obligations.
The manufacturer exits the market or ceases trading. This is the scenario the safety net specifically addresses. The product support obligation continues in principle but is no longer practically deliverable by the original obligor. The asset owner's position depends on what was provisioned in the original procurement — the escrow arrangements, the transition support commitments, the source code access that the next section describes.
The safety net: escrow, transition support, decommissioning
Source code escrow is the most consequential element of the safety net for industrial equipment. For critical firmware components — programmable logic controller code, converter control software, safety-instrumented system code, the bootloader and secure boot chain, the protocol implementations — source code is deposited with a neutral third-party escrow agent under a deed of escrow. Common escrow agents for industrial software include NCC Group's Escode, Iron Mountain's escrow services, and Lloyd's Register for higher-assurance arrangements.
The deed specifies release triggers. The triggers commonly include manufacturer insolvency or cessation of trade, the manufacturer's failure to provide security patches within agreed timelines, the manufacturer's refusal or inability to remediate a critical vulnerability, and the expiry of the declared support period without a renewal commitment. On release, the source code becomes available to the asset owner or a designated successor service provider, with documented build instructions, dependency lists, and the technical artefacts required to make the code maintainable.
Escrow is more than the source code itself. It typically includes the build environment specifications, the test suite, the documentation of the development practices that 62443-4-1 conformance requires, the cryptographic signing keys (or their reset procedure), and the supplier contacts for any third-party components incorporated in the firmware. Without these, source code alone is not enough to continue maintenance; with them, a competent engineering organisation can take over the support function.
Transition support obligations are the second element. The manufacturer commits to a defined period of transition assistance if the service agreement is not renewed or if the manufacturer is exiting the market — typically twelve to twenty-four months, with documented deliverables: training for the successor service organisation, documentation packages, spare parts inventory transfer, and access to engineering support for specific technical questions during the transition window. The transition support obligation is contractual rather than regulatory; the asset owner negotiates it at procurement and the manufacturer commits to it as a condition of the project.
Secure decommissioning is the third element, addressing the end of the asset's operational life. When the equipment is retired, the cryptographic material it holds — private keys for PKI integration, stored credentials, certificates — must be securely erased before disposal. The asset owner's PKI revocation infrastructure must record the revocation of the device's certificates. The configuration data must be sanitised. Physical disposal must follow the relevant waste electrical and electronic equipment regulations in the host country and any applicable extraterritorial obligations.
Each of these — escrow, transition support, decommissioning — is a deliverable the asset owner provisions at procurement and exercises at specific lifecycle points. None of them comes for free; each is a cost the manufacturer's bid must include. The cost is modest in absolute terms but disproportionately important if the unlikely scenarios materialise.
At proposal stage
A manufacturer's bid that addresses the lifecycle question explicitly — that states the declared support period and shows it aligned with the asset's operational lifetime, that includes source code escrow arrangements with documented release triggers, that commits to transition support with specific deliverables and timelines, and that addresses secure decommissioning — is a bid that has anticipated the conversation. The lender's compliance team reviews the lifecycle pack alongside the other submissions; the conversation that follows is about specific terms rather than about whether the manufacturer has thought through the long horizon.
A bid that conflates the service agreement term with the regulatory support obligation, or that proposes only the LTSA without addressing what happens at year six and beyond, signals a gap. The gap is not unbridgeable. A declared support period can be stated separately. An escrow deed can be negotiated with one of the established agents in three to four weeks. Transition support commitments are standard contractual language. The work is procurable from established suppliers; the manufacturer's task is to recognise that the work is required.
The deeper observation is that the manufacturer's product strategy and the asset owner's project strategy operate on different timescales. The manufacturer's product roadmap may include end-of-life for a product line within ten years; the asset's operational life is two to three times that. The CRA's declared support period formalises this tension and forces the manufacturer to think about lifecycle commitments differently than historical practice has required. Manufacturers who internalise this — declaring meaningful support periods, building escrow into their standard offer, treating transition support as a service rather than a one-off — are positioned for a market in which lifecycle commitments are a procurement criterion rather than a contractual footnote.
The next article picks up the people and procedures that span all of these lifecycle questions: the personnel certifications, background checks, training discipline, and insurance arrangements that the manufacturer's service organisation needs to maintain across the support period, regardless of which commercial vehicle is in place at any given time.
This article reflects the regulatory and commercial landscape at publication. The Cyber Resilience Act's implementing acts continue to be issued through 2026 and 2027 and may clarify or alter specific support period obligations. References to escrow agents and operations and maintenance providers are illustrative rather than endorsements; specific arrangements should be reviewed by qualified counsel. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.