Product support periods
The support period is the window during which we provide security updates for a product. Knowing where your system sits in that window tells you whether a newly published advisory applies to you and whether a fix will be issued.
Current support periods
| Product family | First placed on market | Security updates until | Status |
|---|---|---|---|
| GDSLAB v202x | Per release | Five years from each release | Supported |
| GDSBES v202x | Per release | Five years from each release | Supported |
| GDSBES v3 | To be confirmed | 31 December 2026 | Ending |
| GDSBES v2 | To be confirmed | To be confirmed | Support ended |
| GDSLAB 2.x | To be confirmed | To be confirmed | Support ended |
If you have a GDS instrument rather than a software licence, its firmware support period is being set as part of our product lifecycle work and will be added here. Until then, send us the serial number and we will tell you where your system sits.
How the v202x versions work
GDSLAB v202x and GDSBES v202x are each one continuing product, not a new one every year. Releases are named by year — v2025, v2026 — and there is normally more than one in a year, with each building on the one before rather than replacing it.
Each mainline release carries its own five years of security updates, counted from its release. You do not have to move up the line to stay covered: if you were commissioned on v2025 and your laboratory cannot revalidate every year, v2025 goes on receiving security fixes for five years from the day it shipped. Moving to a later release gets you new functionality, not the right to be secure.
To identify your version: in GDSLAB choose Help → About; for instrument firmware, read the version from the controller display or the serial label. If you are unsure, send the serial number to support@gdsinstruments.com and we will tell you where your system sits.
What a support period covers
During the support period we will:
- Investigate reported vulnerabilities and fix or mitigate those that apply to the product
- Publish an advisory when a security update is released
- Provide security updates free of charge, whether or not you hold a support contract
- Issue security-only updates separately from feature releases where that is technically feasible, so you are not forced to take functional changes to become secure
- Maintain a software bill of materials for the product — see software transparency
Security updates are free
A lapsed support or maintenance contract does not stop you receiving security updates for a product still within its support period. Support contracts cover application help, calibration and functional upgrades — not security fixes.
How we set the support period
Article 13(8) of the Cyber Resilience Act requires the support period to reflect how long the product is reasonably expected to be in use, and to be at least five years unless the product's expected lifetime is shorter.
Geotechnical testing apparatus is long-lived. A triaxial frame installed today may still be in service in twenty years — not running one continuous test, but in regular use — and we support instruments older than the engineers operating them. That pulls the two halves of a system apart, and we set them separately:
- Control and analysis software — five years from each mainline release, reflecting the operating systems and dependencies it is built against. Each release carries its own five years, so you are not pushed up the line to stay covered.
- Instrument firmware — longer, set against the service life of the hardware generation rather than a software release cycle. We are setting these per generation and will publish them here.
We take into account how long the hardware is expected to remain in service, how long comparable products are supported, how long the core components remain available from our suppliers, and how long the underlying operating systems receive support from their vendors.
How long updates stay downloadable
Once we have issued a security update we keep it available for download for at least ten years after the product was placed on the market, or for the remainder of the support period if that is longer. That applies even after the support period ends — you can still obtain the last security update for a product we no longer actively maintain.
When support ends
We publish the end-of-support date in advance rather than announcing it retrospectively, and we write to known users of the product family at least twelve months beforehand.
After the end of support we will not investigate new vulnerability reports against the product, will not issue security updates for it, and will not publish advisories for it. The product will keep working; it simply will not be maintained.
Running an unsupported system
Laboratories often cannot replace a working apparatus on a software vendor's timetable, and we would rather help than lecture. If you are running an unsupported version, talk to us about the upgrade path — in many cases the control software can be updated while the apparatus and transducers stay exactly as they are. Where an upgrade genuinely is not viable, we can advise on isolating the system so that an unmaintained machine is not exposed to your wider network.
Modified systems
If you substantially modify a product — for example by replacing our control software with your own, changing the firmware, or integrating third-party hardware into the control loop — talk to us about what it means for support. We cannot stand behind behaviour we did not build, and a fix we issue may not apply cleanly to a system that no longer matches what we shipped. Whether a change takes a system outside its support period depends on what was done: adding a third-party transducer is not the same as replacing the control software, and we would rather look at it than apply a blanket rule.
Whether that also moves regulatory responsibility is a narrower question than it is often taken to be. Article 22 of the Cyber Resilience Act treats someone who substantially modifies a product and makes it available on the market as its manufacturer — for the part affected, or for the whole product where the modification affects the cybersecurity of the whole. Modifying an instrument for your own laboratory’s use is not making it available on the market, so it does not make you a manufacturer under the Regulation. Rebuilding our apparatus and selling it on may well do.
“Substantial” has a defined meaning here as well: a change made after the product was placed on the market that affects its compliance with the Annex I essential requirements, or that changes the intended purpose it was assessed against. Configuration, calibration and ordinary use are not substantial modifications. If you are planning something and are unsure which side of the line it falls, ask us before you commit — that conversation is easier to have in advance than afterwards.