How to set a CRA support period that holds up to scrutiny
Article 13(8) asks manufacturers to set a support period that is at least five years long, or that matches the expected use time when a product will be in use for less than five years. The period must reflect reasonable user expectations and the nature and intended purpose of the product. Its purpose is to stop a product from reaching users with an open-ended exposure to vulnerabilities that nobody is obliged to handle. Once a product is sold with a promised window of coverage, customers plan around that window, and the manufacturer must keep handling vulnerabilities until it ends. What makes this hard is that the number alone is not enough. The reasoning behind the period must be documented, because the information used to determine it belongs in the technical documentation. A defensible file records the expected use time for the product category, the user expectations you considered, the intended purpose, and any relevant Union law on product lifetime. Commission guidance adds that each substantially modified software version placed on the market must declare its own support period, so a major release can reset the clock and needs its own reasoning. Ask engineering, product management and legal to agree the rationale before launch, and keep it under version control so you can show how and when the decision changed.
Next, the end date has to be fixed before purchase. Article 13(19) requires the end date, with at least the month and year, to be clearly specified at the time of purchase and, where applicable, on the product, its packaging or by digital means. Check that the date in the sales channel, the product documentation and the device or software itself all match. Market surveillance authorities monitor how manufacturers set these periods, so a period that is short for the product category, with no written justification, is the first thing an inspector will question. Commission FAQ 4.5.2 names longer expected lifetimes for products such as routers, operating systems and industrial control systems, which is a useful reference when you explain why your period is longer than the minimum. Confirm the category-specific figures against the current Commission FAQs and any ADCO guidance before you commit to a date.
Which products and versions the support period applies to
Article 13(8) attaches to every in-scope product with digital elements, but the work changes with three questions: how long the product stays in use, which classification it falls under, and whether a legacy product is caught at all. Each card below is a decision point that determines the support period a manufacturer must declare.
Products expected to stay in use longer
The Commission's FAQ names motherboards, microprocessors, routers, modems, switches, operating systems, video-editing tools and industrial control systems as products typically used for more than five years. For these, the support period must reflect expected use time, so the five-year minimum is a floor, not a target. Check the product's realistic service life against reasonable user expectations and record the reasoning in the technical documentation.
Products used for less than five years
Where a product is expected to be in use for less than five years, Article 13(8) sets the support period at the expected use time instead of five years. This is a narrow case that needs evidence, not an assumption. Document the basis for the shorter period, because market surveillance authorities monitor how manufacturers set these periods and can ask for it.
Each substantially modified software version
Guidance C(2026) 5252 says each substantially modified software version placed on the market must declare its own support period that complies with Article 13(8). A new major release that changes core functionality therefore needs its own end date, and an older version does not silently inherit a longer or shorter one. Track which releases count as substantial modifications before you ship them.
Classification that sets the work
Whether a product is default, important (Annex III class I or II) or critical (Annex IV) shapes the conformity route, and therefore how much support-period evidence an assessor expects. Confirm the classification first, because it determines whether a notified body reviews the file. Your product's core functionality, not its marketing category, drives the result.
Legacy products placed before the application date
Products placed on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified from that date. Confirm the release history and the date each unit left your control, since shipping stock and cloud-delivered updates can complicate that record. Reporting duties under Article 14 apply regardless of when a product was placed on the market.
Expected use inputs to document
Article 13(8) requires the information used to set the support period to appear in the technical documentation, under Annex VII point 4. Gather usage data, customer contract terms, sector lifetime expectations and any Union law on product lifetime into one file. Ask your legal and product teams to confirm which inputs they will defend if an authority asks.
How an assessor tests the support period declaration
This table sets out each check an assessor runs on the support period declaration under Article 13(8), the evidence requested for it and the findings that most often appear. Read it as a checklist you can run against your own declaration before a market surveillance authority or notified body asks for it.
| Check | What the assessor tests | Evidence requested and common findings |
|---|---|---|
| Stated period against the floor | The declared period is at least five years, or, if the product is expected in use for less than five years, it matches the expected use time | Declared period in the technical documentation. Finding: a period under five years with no expected-use analysis behind it |
| Justification in technical documentation | The information used to set the period is recorded, covering reasonable user expectations, intended purpose and relevant Union product lifetime law | Written rationale in the technical documentation (Annex VII point 4). Finding: a bare number with no reasoning or source |
| Product category expectations | The period reflects the longer lifetimes Commission FAQ 4.5.2 describes for categories such as routers, switches, operating systems and industrial control systems | Category analysis and comparison with market practice. Finding: a short period set for a category normally used for longer |
| End date at purchase | The end date, with at least month and year, is shown clearly at the time of purchase and, where applicable, on the product, packaging or digital means | Sample of purchase pages, packaging, onboarding screens and checkout text. Finding: only a year given, or the date appears only in a PDF the buyer must find |
| Consistency across versions | Each substantially modified software version declares its own support period that complies with Article 13(8) | Version list, release notes and per-version declarations. Finding: a new major version that inherits an older end date without its own justification |
| Alignment with the vulnerability process | The support period matches the period in which the manufacturer actually handles vulnerabilities under Annex I Part II | Support policy, patch records and advisory history. Finding: published end date passed without notice or updates still shipping |
| Delegated act and authority guidance | Any minimum set for the product category by delegated act, and indicative periods from ADCO, are considered | Confirm current category rules with the Commission and ADCO outputs before the assessment. Finding: a period that conflicts with a published category minimum |
Steps to set, document and publish the support period
This sequence moves from understanding how long a product is actually used to a published end date and a documented rationale that an assessor or market surveillance authority can check. Each step leaves a record, so the support period can be defended when it is reviewed or challenged.
Define the expected use time
Product management and the security lead estimate how long the product is expected to stay in use, based on its nature, intended purpose and the typical lifespan of comparable products in the market. Consider how customers deploy it, whether it sits in long-lived infrastructure, and what replacement cycles look like. The output is a written estimate with the reasoning behind it. The step is complete when a named owner has signed off on the figure and its assumptions.
Document reasonable user expectations
Map what buyers, operators and sector regulators reasonably expect from the product over its life, using sales materials, contract terms, customer feedback and relevant Union product law on lifetime. Record where expectations point to a period longer than the expected use time, because Article 13(8) asks the manufacturer to weigh both. The output is a short expectations note linked to the product's technical documentation. The step is complete when the note states which sources were used.
Check for delegated acts and ADCO guidance
Before choosing a period, check whether the Commission has adopted a delegated act setting a minimum support period for the product's category, and review any indicative periods or statistics published by the administrative cooperation group. The Commission guidance also addresses support periods, so read that section alongside the regulation. The output is a record of what was checked, the date of the check and any minimum that applies. The step is complete when the team confirms whether a category minimum exists or that none has been published yet.
Choose the support period
Set the period at no less than five years, unless the expected use time is shorter, in which case the period matches that expected use time. Where the expected use time or expectations point to a longer life, extend the period to reflect them. Product owners approve the chosen period and legal or compliance review confirms it meets the minimum. The output is an approved support period expressed as an end date with at least month and year. The step is complete when the approval is recorded with the approver's name and date.
Record the rationale in technical documentation
Write up the expected use time estimate, the expectations analysis, any category minimum or ADCO guidance applied, and the reasoning that produced the final period. Store it in the technical documentation under the Annex VII point 4 reference, using a version-controlled wiki or document system so every change and approver is traceable. The output is a rationale document that an assessor can read without interviewing the team. The step is complete when the document is linked from the product's technical file index.
Publish the end date at purchase and per version
Show the end date, including at least month and year, clearly at the point of purchase, and place it on the product, its packaging or in a digital channel where applicable. Give each substantially modified software version its own declared period, since the Commission guidance expects each version placed on the market to declare one. The output is a set of published end dates tied to each product and version. The step is complete when a reviewer can find the end date on the purchase page and on the release notes for each version.
Review the period on substantial modification
Trigger a review whenever a release is a substantial modification, and whenever a new delegated act, ADCO guidance or change in expected use time appears. Re-run the earlier steps for the new version and record whether the period is unchanged, extended or newly declared. The output is a dated review entry linked to the version's rationale and published end date. The step is complete when the release checklist cannot be closed without this entry.
Why the expected use time, not the marketing, sets the period
The expected use time sets the support period, and marketing language does not. Article 13(8) asks the manufacturer to set a period that reflects how long the product is expected to be in use, weighing three factors together: the nature and intended purpose of the product, reasonable user expectations, and relevant Union law on product lifetime. The five-year minimum is a floor. A product that a reasonable customer keeps for longer is expected to carry a longer period, and a product that is marketed as long-lived but realistically replaced after three years cannot justify a short period by pointing to its brochure. The Commission's FAQ 4.5.2 gives illustrative examples of products typically used for more than five years, including routers, modems, switches, operating systems and industrial control systems. An operating system or an industrial controller installed for a decade will need vulnerability handling for that decade, whatever the product page says about its refresh cycle.
The three factors interact. Intended purpose narrows the field: a router sold for home broadband and one sold for a utility's substation network serve different users with different replacement habits, so they can justify different periods. Reasonable user expectations test the claim from the buyer's side, and a buyer who would be surprised to find updates stop after two years is a signal that the period is too short. Relevant Union law on product lifetime adds a constraint that the manufacturer must check against its own product category rather than assume. Confirm which lifetime rules apply to your product category before you set the number, because they may point in a different direction from your sales data.
The number matters less than the reasoning behind it. Article 13(8) requires the information used to determine the support period to be recorded in the technical documentation, and market surveillance authorities will ask how the period was reached, not just what it is. Keep a dated record that names the intended purpose, the expected use time and its source, the user expectations you assessed, the lifetime rules you checked, and who approved the decision. Revisit the record when the product changes substantially, because each substantially modified software version must declare its own compliant period under the Commission's guidance. Ask any outside adviser to review this rationale as part of the technical documentation, and confirm with your national market surveillance authority how it expects the evidence to be presented.
Evidence that shows the support period is set and disclosed
Article 13(8) support period evidence sits in four places: the technical documentation, the decision record behind the period, the end-date notice given to buyers, and the declaration for each software version. Each artifact should point to the same end date, so an assessor or market surveillance authority can trace the period from the purchase notice back to the reasoning that produced it.
Rationale in technical documentation
Article 13(8) requires the information used to set the support period to appear in the technical documentation under Annex VII point 4. Record the expected use time, the reasonable user expectations, the intended purpose and any product lifetime rules that apply. Re-check the rationale whenever the product's intended use, market or hardware generation changes, and confirm the stated end date still matches the one shown to buyers.
Version-controlled decision record
Keep a dated record of how the support period was chosen, including who approved it and which factors weighed most. A wiki with page history works well because each change shows what changed, when and by whom, and older versions can be compared or restored. Review the record at each release and before any change to the end date, so the reasoning an assessor reads matches the period actually promised.
End-date disclosure at purchase
Article 13(19) requires the end date of the support period, stated with at least month and year, to be clear at the time of purchase. Check that the sales page, checkout flow, order confirmation and license terms all show the same month and year. Ask the sales and documentation owners to confirm this in each release cycle, since a mismatch between channels is an easy finding to make.
Packaging or digital notice
Where the product has packaging or a digital interface, the end date may also be shown there, or by other digital means where that applies. Capture screenshots, print proofs and the text of in-product notices with their version numbers. Refresh these captures whenever the interface or packaging changes, so the evidence reflects what a buyer saw at the point of sale.
Per-version support declaration
Commission guidance C(2026) 5252 states that each substantially modified software version placed on the market must declare its own support period that complies with Article 13(8). Keep a register that lists each version, its release date, its declared end date and the reason it was treated as substantially modified or not. Confirm that every shipped version has an entry before release, and archive the entry when the version reaches end of support.
Keeping evidence current between audits
Assign one owner for the support period file and tie reviews to existing release and procurement gates rather than a separate calendar. Store the documentation, decision record, notices and version register together, with an audit trail showing each change. Ask your assessor which review cadence and retention period they expect, since these are not fixed by the regulation's supplied text.
Which self-hosted tools keep support period records current
A support period is only defensible if you can show which software version it covers and which components that version ships with. An SBOM gives you that link. Each substantially modified version should have its own SBOM, so the record of its components sits next to the support period it declares.
- Dependency-Track (Apache-2.0): consumes and produces CycloneDX SBOMs and VEX, so you can store one SBOM per released version and see which components carry known vulnerabilities or are outdated.
- Trivy (Apache-2.0): identifies OS packages and software dependencies in a target and can produce them as an SBOM, which you can generate in the build pipeline for each version.
- License tracking: Dependency-Track tracks license use by component using SPDX license IDs, which helps when a component's license terms affect how long you can keep supplying it.
- Version mapping: keep the SBOM identifier, version number and declared support end date together so an assessor can trace each one.
- Component changes: a new SBOM for each version shows what changed between versions, which supports the question of whether a modification is substantial.
Confirm with your team which SBOM format and version identifiers your release process will use, and check the current documentation for how each tool imports and exports data in your environment.
The support period decision rests on reasoning: expected use time, reasonable user expectations, the nature of the product and any relevant Union law on product lifetime. That reasoning and the wording of the end date disclosure both need a home where they can be reviewed, changed and traced. A wiki with version history fits this job, because the record of who changed a justification and when becomes part of the evidence.
- XWiki (LGPL-2.1-or-later): keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back.
- Rationale pages: one page per product version holds the factors considered, the expected use time and the resulting period.
- Disclosure text: store the exact wording used for the end date at purchase, including month and year, so the published text can be matched to the approved record.
- Review history: version comparison shows when a period was shortened or extended and what justification was given at the time.
- Technical documentation links: reference the wiki page from the technical documentation that must include the information used to set the period.
Confirm with your compliance lead how long records must be retained and whether the wiki's export and backup options meet your retention rules.
Support periods should be approved by people with the authority to commit to them, and the approval should be separated from the people who draft the rationale. Access controls in your documentation and tooling make that separation visible and provable to an assessor or market surveillance authority.
- BookStack (MIT): user abilities come from assigned roles, and permissions can be overridden per role at the shelf, book, chapter or page level.
- Approver role: give only designated approvers the ability to publish or edit a support period page, and keep drafting rights separate.
- Scoped permissions: restrict each product's support period pages to the product team and compliance reviewers, so changes to one product do not affect others.
- Dependency-Track access: restrict who can change component status or VEX decisions, since those decisions feed the vulnerability handling that the support period depends on.
- Audit trail: pair role-based access with the version history from the wiki so each approval can be traced to a named person.
Confirm how your identity provider integrates with each tool, and document the approval workflow in your own process before you rely on the tooling to enforce it.
What meeting the support period requirement costs
This table compares each cost component of setting and disclosing an Article 13(8) support period, who is paid for it, whether it is one-time or recurring, and what drives it up. Read it as a checklist for requesting a fixed-scope quote, since no supplied figures exist for these costs. The main takeaway is that most of the expense recurs with each new product line, version and substantial modification, so the support period decision should be made once and documented as a repeatable process.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it and what to ask for |
|---|---|---|---|
| Engineering time to define expected use time | Internal product and engineering staff, or an implementation partner preparing the analysis | One-time per product line, revisited on change | Number of product lines and their intended purpose. Ask the partner to state which inputs and sources the analysis will cover. |
| Legal or compliance review | Internal legal counsel or an outside EU product law adviser | Recurring with each new release cycle | Breadth of relevant Union product law and reasonable user expectations. Ask whether review is included in scope or billed separately. |
| Technical documentation upkeep | Internal documentation owners, or a partner maintaining the record | Recurring | Volume of versions and how often the information used to set the period changes. Ask how the record is versioned and who approves changes. |
| Disclosure changes on packaging or digital channels | Internal marketing, packaging, web and product teams, plus print or content vendors | One-time setup, recurring when wording or packaging changes | Number of SKUs, packaging runs and digital storefronts. Ask which channels are covered and how the end date is updated across them. |
| Substantially modified versions | Internal engineering, with compliance review for each modified version | Recurring per modified version | Modification frequency. Each substantially modified version must declare its own support period, so frequent releases multiply this work. |
| Assessor time | Independent notified body or other assessor, where a conformity route requires one | Recurring at each assessment cycle | Scope of the review and the quality of the documented rationale. Ask the assessor for its written scope and the evidence it expects. |
| Open-source tooling for evidence | Typically no licence fee for the tooling itself, though staff time to operate it is still paid | One-time setup, recurring operation | Tools such as Dependency-Track and Trivy are Apache-2.0 licensed, so licence spend is reduced. Staff time for configuration and upkeep still applies. |
| Ongoing support and retainer | Implementation partner under a retainer, if one is agreed | Recurring | Whether support, upgrades and reviews are in scope. Ask for a written scope that separates one-time delivery from ongoing work. |
Where support period declarations usually fall short
Most support period problems are not about picking the wrong number. They come from declarations that were copied, never updated, or not backed by records an assessor can read. Each card below names one gap, why it matters under Article 13(8), and the fix to put in place before a product is placed on the market.
One period copied across product lines
A single support period is often pasted into every datasheet, even though a router, a mobile app and an industrial controller are expected to stay in use for very different lengths of time. Article 13(8) ties the period to expected use time, so one figure for all products is hard to defend. Fix: set the period per product or product family, and record the expected use time that justifies each figure.
Period shorter than expected use time
Teams sometimes choose the five-year minimum for a product that is expected to be in use for longer, such as a motherboard, a router or an industrial control system. The regulation requires the period to reflect expected use, and the Commission FAQ names these categories as ones where longer periods are expected. Fix: compare the declared period with the expected use time for each product and document why any shorter period applies.
End date without month and year
A declaration that gives only a year, or says "long-term support", does not meet the end date requirement for purchase information. Article 13(19) requires at least the month and year to be clearly stated at purchase and, where applicable, on the product, its packaging or by digital means. Fix: publish a specific month and year in the product page, the packaging or the on-device information, and check that the date matches the technical documentation.
Substantially modified versions without a declaration
A new release that changes the software substantially may keep the old support statement by habit. Commission guidance C(2026) 5252 says each substantially modified software version placed on the market must declare its own support period that complies with Article 13(8). Fix: add a release gate that asks whether a version is substantially modified and, if so, requires a fresh support period and end date before release.
Rationale missing from technical documentation
Teams often settle a period in a meeting and never write down the reasoning. Article 13(8) requires the information used to determine the support period to be included in the technical documentation, and market surveillance authorities can ask to see it. Fix: keep a versioned record of the expected use time, the user expectations, the product purpose and any relevant Union law, and link it from the technical documentation.
Rationale changes without a version history
Even when the reasoning is written down, it may be overwritten when the period is revised, so the record no longer shows what was declared at placing on the market. A reviewer then cannot tell which justification applied to which version. Fix: store the support period record in a tool that keeps every change with its author and date, so earlier declarations can be compared and restored.
Questions buyers ask about the CRA support period
How long does the CRA support period have to last?
The support period must be at least five years under Article 13(8). If a product is expected to be in use for less than five years, the support period must match that expected use time instead. The manufacturer sets the period, but it must reflect how long the product is realistically expected to be in use, considering reasonable user expectations, the product's nature and intended purpose, and relevant EU law on product lifetime. Commission CRA FAQ 4.5.2 says longer periods are expected for products typically used for more than five years, such as motherboards, microprocessors, routers, modems, switches, operating systems, video-editing tools and industrial control systems. Confirm the category your product falls into before you commit to a date.
Can our in-house team set the support period without outside help?
Yes, the manufacturer sets the support period, so your own product, legal and security staff can make the decision. The harder part is documenting it. Article 13(8) requires the information used to determine the support period to be included in the technical documentation, so your team needs a written record of the expected use time, the user expectations considered and the product lifetime rules relied on. Teams that already maintain product documentation and a vulnerability process usually find this manageable. Teams without a record of their component lifecycles may need more time to gather the inputs.
What does an implementation partner handle for the support period?
An implementation partner such as DeployOpen can prepare the systems and evidence that support the period you set. Under a fixed-scope engagement, that work typically covers collecting component and version data, keeping the technical documentation current, and setting up records that show the vulnerability process runs for the whole support period. The partner does not decide the period, own the controls, or issue conformity documents. The organization remains responsible for the declared date, and an independent assessor or notified body checks the conformity route where one applies. Scope, deliverables and timelines are agreed in writing before work starts, so ask for the list of artifacts included.
How much effort does documenting the support period take?
Effort depends mainly on how many products and versions you ship, how many third-party and open-source components they contain, and how well your existing records are organized. The one-time work is defining the period for each product, writing down the justification and linking it to the technical documentation. Recurring work is keeping that justification current as products change and as components approach end of life. The CRA does not set a fixed number of hours, so ask any provider for an effort estimate tied to your product inventory, and treat that estimate as the basis for the quote.
What happens to the support period when a product is substantially modified?
Each substantially modified software version placed on the market must declare its own support period that complies with Article 13(8). According to Commission guidance C(2026) 5252 (section 5), a major change does not simply extend the old date. Your team should record which version the period applies to, the end date, and the reasoning behind it. Products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified from that date, so confirm with counsel whether a planned change counts as substantial before you release it.
Where must the end date be shown to buyers?
Article 13(19) requires the end date of the support period, including at least the month and year, to be clearly specified at the time of purchase. Where applicable, it must also appear on the product, its packaging or through digital means. Engineers should plan for this in the product and storefront flows, not only in marketing copy. Check the exact display requirements against the regulation text and your sales channels, especially for software delivered through app stores or download pages.
What will an assessor ask for about the support period?
An assessor or market surveillance authority will ask for the declared end date, the basis for it, and proof the vulnerability process runs until that date. Expect requests for the technical documentation section showing the information used to set the period, the expected use time and user expectations considered, the version history for substantial modifications, and records showing how support was delivered. Under Article 52(16), market surveillance authorities monitor how manufacturers set support periods, so keep the reasoning current and retrievable. Versioned documentation tools such as XWiki, which keeps a history of changes by page, can help show when a position was recorded.
Who sets the period, who prepares evidence and who assesses it
The manufacturer decides the support period and remains fully accountable for it. Article 13(8) asks for a period that reflects how long the product is expected to be in use, considering reasonable user expectations, the nature and intended purpose of the product, and relevant Union law on product lifetime. Product management, legal and security leads usually own that judgment, and the rationale they record becomes part of the technical documentation.
- Expected use time: Product owners document how long customers realistically keep the product, with the data or market evidence behind that view.
- Intended purpose and user expectations: Legal and product teams record what the product is sold for and what buyers reasonably expect.
- Five-year floor: The team confirms whether the five-year minimum applies or whether a shorter expected use time governs.
- Substantial modifications: Release managers decide when a new software version needs its own declared period.
- Sign-off: A named executive approves the period and the rationale in writing.
Before the period goes to market, confirm that the rationale is stored in the technical documentation and that the decision owner can explain it to a market surveillance authority.
An implementation partner prepares the systems that hold the support period, the rationale and the disclosure of the end date. The partner does not choose the period or certify it. Its work is to make the decision traceable, versioned and visible at the point of purchase. DeployOpen, for example, can help configure the record-keeping and publishing workflow inside the client's own infrastructure, subject to a written scope.
- Records: Set up a controlled wiki or documentation space where each support period, its justification and its approval are stored with version history.
- Version mapping: Link each released software version to its declared end date so that substantially modified versions carry their own period.
- Disclosure workflow: Prepare the product page, packaging text or digital notice that shows at least the month and year of the end date at purchase.
- Component data: Connect software bills of materials to the release record so the team can show which components sit inside each version.
- Access control: Restrict who can edit support period records and keep an audit trail of changes.
Ask the partner which parts of the workflow it configures and which parts remain with your staff, and who keeps the records after the engagement ends.
Market surveillance authorities check whether manufacturers set support periods correctly, and conformity assessment bodies may review technical documentation where a notified body is involved. Under Article 52(16), authorities monitor how manufacturers set these periods, and ADCO publishes statistics and indicative guidance by product category. Independence means the assessor tests the manufacturer's record and never writes it.
- Document review: Assessors read the stated period, the rationale and the evidence used to justify it.
- Consistency checks: They compare the declared end date with the product's public disclosure and its version history.
- Category comparison: They compare the period with ADCO guidance and Commission FAQ examples for similar product types.
- Modification tests: They check whether each substantially modified version declares its own compliant period.
- Limits: Assessors do not design the period or prepare the evidence for the manufacturer.
Confirm with your conformity route whether a notified body will review this documentation, and ask what format it expects for the rationale.
How DeployOpen prepares support period evidence for your products
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and prepares the systems and records that show how your support period was set and kept. Your organization owns the support period decision, and only an independent assessor or authority reviews it.
How we scope
- Agree in writing which products, software versions and support periods the engagement covers before any work starts.
- Record the expected use time, intended purpose and user expectations you have for each product as the starting inputs.
- Confirm which Article 13(8) inputs your organization must decide itself and which parts DeployOpen can prepare for review.
How we build
- Set up version tracking so each substantially modified software version has its own recorded support period.
- Configure SBOM generation and component inventories so the dependencies behind each support period are visible and traceable.
- Test that vulnerability tracking keeps working through the full support period, including for components you no longer ship.
How we hand over
- Deliver the support period rationale in a structure ready for the technical documentation your organization maintains.
- Document the end date process so the month and year shown at purchase can be traced back to a recorded decision.
- Provide runbooks and version-controlled records so your team can update the evidence without relying on the implementation partner.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if you want help as the regulation's guidance and standards evolve.
- Review support period records when a product is substantially modified or its expected use time changes.
- Confirm with your legal and compliance team how the final support period position fits your obligations before you rely on it.
