CRA for B2B and tailor-made enterprise software

Does the Cyber Resilience Act apply to B2B and tailor-made enterprise software?

The Cyber Resilience Act for B2B software applies to software with digital elements sold to businesses, and the business customer does not change that. The tailor-made exception is narrow: it covers only the secure by default configuration and the free of charge security updates required under Annex I, and only when the manufacturer and the business user explicitly agree different contractual terms for a product fitted to a particular purpose. Vulnerability handling, the support period, the Article 14 reporting duty and the technical documentation still apply in full. A contract clause cannot remove them. What changes the answer is first whether the product is tailor-made or standard. A bespoke system built for one customer, with the terms documented in the contract, can use the exception for defaults and updates. A product offered to many customers on the same terms cannot, even if each sale involves negotiation. Ask legal and engineering to write down which defaults were agreed, which updates are free, and which are priced, and keep that record with the technical file. Confirm with counsel how the contract wording maps to the recitals before relying on it.

The second question is how the software is versioned and deployed. Where a successive version is substantially modified, Article 13(10) allows remediation only in the latest version, but only if earlier users can get that version free of charge without additional costs to adjust their hardware and software environment. Under the Commission guidance, routine testing, configuration changes and dependency upgrades are not additional costs, while mandatory new hardware or infrastructure replacement may be. Each substantially modified version must also declare its own support period. For variants, one risk assessment, one technical documentation set and one conformity assessment can cover variants that share architecture and risks, but differences in interfaces, software stacks or update mechanisms must be reflected. Automatic updates are not expected in professional environments and integrated components, so confirm with your customers how their change windows and update processes work before setting the update design.

When automatic updates are not expected in professional environments

Commission FAQ 4.3.3, citing the CRA recitals, says automatic update requirements do not cover every product. The cases below describe where manufacturers may depart from automatic delivery, and what they must document and agree with business users before relying on that position. Each case needs confirmation against the FAQ text and the customer's own environment before it is used in a contract or technical file.

Products intended for component integration

A library, module or firmware block built to be integrated into another manufacturer's product is often not something end users would expect to update automatically. The integrating manufacturer controls when and how the component is deployed. Document the integration model, the update channel the integrator uses, and the notice you give so that patches reach the integrator in time to ship. Confirm with the FAQ that this product is primarily intended for integration as a component.

Change-controlled production systems

Plants, hospitals and data centers often require that every software change passes qualification before it reaches production. Automatic installation would bypass that control. Record in the contract that updates are delivered as signed packages with advisory messages, and that the business user decides installation timing. Confirm this against your own operating environment and the FAQ's reference to industrial environments.

Regulated professional ICT networks

Banks, public bodies and healthcare networks often run software under change advisory boards and audit trails. An unexpected automatic update could breach their own controls. Agree a written update procedure covering notification, test windows and the escalation route for an urgent security patch. Confirm that the business user would not reasonably expect automatic delivery in its network before relying on this position.

Air-gapped or isolated deployments

Systems without outbound connectivity cannot receive automatic updates at all. The manufacturer must still disseminate security updates without delay and free of charge unless otherwise agreed for a tailor-made product. Document the offline delivery method, the verification of update integrity, and who carries the update into the isolated network. Confirm the transfer method with the customer before the support period is declared.

Safety-relevant control software

Software that controls physical processes or safety functions may require validation before any change is applied. Automatic deployment could invalidate that validation. Document the validation evidence each update requires, the customer's approval step, and the interim mitigations you publish if a patch is delayed. Confirm the scope against the FAQ and against any sector regulator that governs the system.

Fixing only the latest version: the Article 13(10) condition

Article 13(10) lets a manufacturer of software with successive substantially modified versions fix vulnerabilities only in the latest version, but only when users of earlier versions can get that fix free of charge and without additional costs to adjust their hardware and software environment. The condition is the whole point. A vendor that ships a fix only to its newest release has not met the CRA simply by saying so. It has to show that moving to the new release does not force the customer to buy hardware, replace infrastructure or absorb costs that would make the upgrade a purchase in its own right.

The Commission's guidance C(2026) 5252 (section 5) gives the working test. Additional costs are burdens such as mandatory purchases of new hardware or infrastructure replacement. Routine testing, configuration adjustments and dependency upgrades are not additional costs under that reading. An enterprise customer should therefore ask the vendor to show, release by release, what the upgrade path requires: which hardware or operating system baselines change, whether any infrastructure must be replaced, which configuration changes are expected, and whether the upgrade is delivered at no charge under the contract. Where the answer depends on a paid licence tier, a hosting element or a required platform change, the latest-version-only policy may not hold for that customer, and the contract should say so.

Before accepting a latest-version-only policy, ask for the upgrade path in writing, the release notes that list environment changes, and the support period declared for each version, since the guidance requires each substantially modified version to declare its own support period under Article 13(8). Confirm with the vendor how it will handle a customer who cannot move yet, and whether its free-of-charge commitment covers that case. Your own team should test the upgrade in a staging copy of the environment before you rely on it. Ask the Commission's CRA FAQs how to read the terms, and take legal advice on any contract clause that limits upgrades.

How versions and variants change the documentation burden

When a software vendor places a substantially modified version of a product on the market, that version needs its own declared support period. Article 13(8) requires the manufacturer to set the support period for each version, and the Commission's guidance in C(2026) 5252 (section 5) makes clear that this applies to each substantially modified version placed on the market, not only to the product line as a whole. The documentation follows the version: the support period, the risk picture and the technical file must describe the release that customers actually run. Assessors will compare the declared period against what customers were told and against the release history, so the record needs to be kept per version.

Declared period per version: each substantially modified release states its own support period, and the statement is kept with that release's documentation.
Release history: a maintained list of versions, their release dates, and which ones are substantially modified, so the support periods can be traced.
Customer communication: the support period given to business users matches the one recorded for that version.
Retirement notices: when a version reaches the end of its declared period, the withdrawal and the advice to upgrade are documented.
Substantial modification tests: a written method for deciding whether a change creates a new version, applied consistently across releases.

Confirm with the Commission guidance and your legal team which changes count as substantial in your product, and check that each release record names its own support period before the version reaches a customer.

Setting and documenting the support period for enterprise releases

This sequence turns the CRA's support period and free-update rules into a version-by-version record that your contracts, release process and published support statements all agree with. Each step leaves a document that an assessor or business user can check.

Identify each substantially modified version
Product management and engineering review every release and decide which ones are substantially modified versions under the CRA. Stock updates such as routine patches or dependency upgrades may not change that status, but the decision needs a written rationale because the guidance treats substantial modification as a judgment call tied to the product's risk profile. Confirm the criteria with counsel and the Commission guidance text before you rely on them. The output is a version register that lists each release, its classification, the reasoning and the approver. The step is done when every shipped version appears in the register with a decision recorded.
Set each version's support period under Article 13(8)
For each substantially modified version, the product team, with legal review, sets a support period that complies with Article 13(8). The Commission guidance says each version placed on the market must declare its own period, so one period cannot be reused across a product line without checking it against every release. Ask counsel to confirm the length and the start date against the regulation and the guidance, because this page does not state any duration. The output is a support period field for each entry in the version register. The step is done when every version has a declared end date and a named owner who will track it.
Map free updates and latest-version fixes to each release
Engineering and legal decide how each version receives security fixes. Under Article 13(10), vulnerabilities may be remediated only in the latest version when earlier-version users can obtain it free of charge without additional costs to adjust their hardware and software environment. The guidance reads additional costs as mandatory hardware purchases or infrastructure replacement, not routine testing, configuration adjustments or dependency upgrades, so document which upgrade path each customer must take and what it costs them. Record the result beside each version entry. The output is an update path table showing, for each version, whether fixes arrive in place or only in a newer release, and the test used to reach that answer. The step is done when no version lacks a documented path.
Write the support period and update terms into contracts
Legal drafts a clause for each business customer contract that states the version or variant covered, its support period, the free security-update policy and any agreed deviation for a tailor-made product. Under the recitals and Annex I, deviations from the essential requirements apply only where the manufacturer and business user explicitly agree different terms, so generic terms in a standard order form are not enough for tailor-made work. The clause should also reference the published support statement rather than repeat it in full, so both stay aligned. The output is a contract schedule per customer. The step is done when the account team can show which schedule applies to each deployed version.
Document the policy in a technical file
Product security and compliance staff compile the decisions from the earlier steps into the technical documentation that supports the product's conformity assessment. The file should show the version register, the reasoning behind each substantial-modification decision, the support periods, the update path table and the contract templates. Where variants share architecture, security-relevant design, intended purpose and risks, the guidance allows one risk assessment, one technical file and one declaration of conformity for them, but differences in interfaces, software stacks or update mechanisms must be reflected in the file. The output is a versioned technical documentation record. The step is done when an independent assessor could trace any shipped version back to its decisions.
Publish the support statement to business users
Product and customer communications publish a support statement for business users that lists each version, its support period, the free-update policy and the latest-version rule where it applies. The statement must agree word for word with the contract schedules and the technical file, so a single owner should approve all three together. Confirm with counsel the exact wording and the channel the CRA requires for informing users. The output is a dated, versioned public support page or document with a changelog. The step is done when the page is live, linked from release notes and the version register records its publication date.
Review and update the record at each release
Each new release triggers the same chain: the substantial-modification decision, the support period, the update path, the contract check and the publication update. Assign one owner to run this checklist and keep the register current, since a missed entry leaves an older version without a documented policy. Use the same review when the Commission or a market surveillance authority issues new guidance. The output is a dated change record in the version register and an updated support statement. The step is done when every release has a closed checklist and the public and contractual documents match the register.

Which contract terms enterprise buyers should negotiate

The CRA lets a vendor and a business customer depart from some essential requirements only for tailor-made products, and only when both sides explicitly agree different terms. The clauses below are the ones where that agreement has to be written down, and each one needs legal review before signature.

Explicit agreement on defaults and reset

Annex I allows a tailor-made product to depart from the secure by default configuration and the reset requirement only where the manufacturer and business user agree otherwise. Buyers should confirm the agreed default settings are written into the contract or a referenced annex, and that the reset capability and its scope are described. Ask the vendor to show the default configuration and the reset procedure as delivered for your deployment. Have counsel confirm that the departure is explicit and tied to this specific product and purpose.

Free or paid security update terms

The default rule requires security updates to be provided free of charge, so any paid arrangement must be a documented, agreed deviation for a tailor-made product. Specify who pays for updates, what counts as a security update, and how updates are delivered without delay after release. Ask for the vendor's written update delivery process and a list of any charges that would apply. Legal review should confirm the pricing language does not blur into charges for ordinary maintenance.

Advisory messages to users

Security updates must come with advisory messages that tell users what changed and what action they may need to take. Buyers should make the content, format and recipients of these messages a contract term, including which of your staff receive them and how quickly. Ask the vendor for a sample advisory from a previous release and confirm who on the vendor side writes and approves it. This keeps your operations team from discovering required actions only after an exploit.

Support period for each version

Each substantially modified software version must declare its own support period, so a single contract date for the whole product is not enough. Require the vendor to state the support end date for every version you run, and to notify you before it ends. Ask for the written support policy and a version map that shows which releases are covered. Confirm the notice period and the remedy if the vendor ends support earlier than declared.

Latest-version policy and cost condition

Article 13(10) allows a vendor to fix vulnerabilities only in the latest version, but only where earlier version users can obtain that version free of charge without additional costs to adjust their hardware and software environment. Under the guidance, additional costs mean burdens such as mandatory new hardware or infrastructure replacement, not routine testing, configuration changes or dependency upgrades. Write the no-additional-cost condition into the contract, and ask for an upgrade impact assessment before you rely on this policy. If an upgrade would force hardware replacement, the policy does not apply to you.

Reporting cooperation between vendor and customer

Vendors must report actively exploited vulnerabilities and severe incidents, and customers often need that information to meet their own reporting and incident duties. Define in the contract how the vendor will share notifications, timelines, affected versions and remediation status with your security team. Ask for the vendor's named contact, escalation path and the evidence it keeps of notifications made. Legal and security teams should agree the process before go-live, since the reporting obligations apply from 11 September 2026.

Who owns the CRA duties and who prepares the evidence

The manufacturer owns every CRA obligation for a product it places on the market, including the essential requirements, the vulnerability handling process and the EU declaration of conformity. For enterprise software, that manufacturer is usually the vendor that builds and distributes the product, even when the work is done for one business customer. An implementation partner such as DeployOpen can prepare the technical documentation, the versioning and support period records, the update pipeline design and the evidence that shows each control operates. It cannot take over the legal responsibility, and it does not issue conformity documents. Only an independent conformity assessment body or, where the route requires one, a notified body issues conformity documents. The organization should be able to say, in writing, which party prepares each artifact and which party signs off on it. The conformity route for most products is self-assessment under module A, where the manufacturer carries out the assessment itself and draws up the EU declaration of conformity. A notified body is needed only in the cases the regulation sets out, such as certain important products where harmonized standards or common specifications are not fully applied, and for class II and critical products. Enterprise software sold to businesses is often assumed to be in the default category, but the reader should confirm the product's classification and route against the regulation's annexes and the Commission's technical descriptions before budgeting for any third-party assessment. The Commission's CRA FAQ is a useful starting point for that check. A practical first step is to name one internal owner for CRA conformity, usually someone with authority over the product roadmap and not only the security team. That owner should then ask any outside partner for a written scope that lists each deliverable, the evidence it will produce, and the artifacts the manufacturer must review and approve. Where a tailor-made contract is involved, the owner should also confirm who holds the record of agreed deviations from the default requirements, because that record is part of the evidence the manufacturer must be able to produce.

Questions enterprise software vendors ask about the CRA

Does a bespoke software project for one business customer count as tailor-made under the CRA?

Only if it is fitted to a particular purpose for a particular business user and both parties explicitly agree different contractual terms. The recitals tie the exception to that bilateral agreement, so a product built once for a customer and then offered to others does not qualify just because it began as a custom project. Check three things: whether the contract names the business user, whether the deviation from the default requirements is written down, and whether the same codebase is reused for other customers. If the code is reused, the product is likely a standard product with a custom configuration, which is a different question. Have counsel confirm the contract language against the recitals and Annex I before relying on the exception.

Does a standard product with custom configuration still qualify for the tailor-made exception?

Usually not. A standard product sold to many customers is placed on the market as a product, and the tailor-made deviations in Annex I apply to a product fitted to one business user's purpose. Configuring a shared product for a customer, such as setting roles, integrating with their identity provider or choosing modules, is normally a configuration adjustment, not a new tailor-made product. The practical test is whether the security-relevant design, default settings and update mechanism are shared across customers. If they are, the secure default and free update duties still apply to the base product. Ask your counsel and notified body contact to confirm where the line falls for your product line.

Can a vendor waive free security updates in a contract with an enterprise customer?

Only for a tailor-made product where the vendor and the business user have explicitly agreed otherwise. Annex I Part II allows the free-of-charge requirement for security updates to be varied in that situation, but the exception does not remove the duty to disseminate security updates without delay or to provide advisory messages to users. For a standard product, a contract clause cannot turn paid updates into a compliant model on its own. Document the agreed terms, the business user's role and the reasons the product is tailor-made. Ask whether the exception is reflected in the technical documentation and support period, since those records are what an assessor will check.

What changes when enterprise software runs on the customer's own servers?

The vendor's obligations generally stay the same, but the operating context changes what the product must do and who performs some actions. On-premises software is still a product with digital elements, so the essential requirements, vulnerability handling and support period apply. What changes is the update path: the customer often controls when updates are installed, and automatic updates may not be reasonably expected in professional environments. The Commission FAQ notes that automatic update duties do not apply where users would not reasonably expect them, such as professional ICT networks. Confirm with your own engineering team how updates are delivered, how the customer is notified, and which parts of the secure default and reset functions the customer can rely on.

What effort do versioning and documentation add when a vendor ships several variants?

The main drivers are the number of substantially modified versions, the number of variants and how much their architecture, interfaces, software stacks and update mechanisms differ. Each substantially modified software version must declare its own support period, and variants that share architecture, security-relevant design, intended purpose and risks can share one risk assessment, one set of technical documentation, one conformity assessment and one EU declaration of conformity. Variants that differ in interfaces, software stacks or update mechanisms must reflect those differences. Ask your team to map variants to their differences before estimating work, and ask any outside provider to price the work per variant family rather than per release.

Can our in-house team handle CRA preparation, or do we need outside help?

Your team can prepare most of the work if it has the capacity and the right skills, and the vendor always owns its product and its compliance claims. The work includes classifying the product, running the risk assessment, building technical documentation, setting up vulnerability handling and an SBOM process, and maintaining the support period. Outside help is most useful for independent testing, notified body engagement where a product needs third-party assessment, and capacity during the build. Check whether your team has staff for each of these areas, who will sign the declaration, and how the work will be maintained after release. A written, fixed-scope quote from any provider should list deliverables, responsibilities and the evidence handed over.

How DeployOpen prepares enterprise software for CRA evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the evidence for Cyber Resilience Act obligations on enterprise software is produced where the software actually runs. DeployOpen prepares systems, controls and evidence; the manufacturer owns its controls, and any report or declaration comes from the manufacturer or an independent assessor.

How we scope

We agree in writing which products, versions and variants fall under the engagement, and which are tailor-made under a separate contract.
The written scope records each business user agreement that changes default configuration or update terms for a tailor-made product.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts; a quote follows from that written scope.

How we build

We configure secure defaults and a reset to original state, and document where a business user has agreed otherwise.
We set up update delivery for professional environments, recording where automatic updates are not expected and why.
We test the support period and the latest-version remediation approach against the variant structure the client actually ships.

How we hand over

We deliver technical documentation, a risk assessment record and a variant map that shows which differences are reflected in each build.
We hand over the configuration, update and test evidence in a form the client's own team and assessors can review.
We document the operating runbooks so the client can keep the evidence current after the engagement ends.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
Retainers can cover re-assessment when a substantially modified version is released, so each version declares its own support period.
Confirm with DeployOpen which obligations the retainer covers and which remain with the client's compliance or legal team.

Cyber Resilience Act for B2B and tailor-made enterprise software