If your business builds software, resells connected products, or offers hosted web applications to UK customers, the compliance picture has shifted considerably over the past eighteen months. Two pieces of legislation are converging to create real obligations: the UK’s own Product Security and Telecommunications Infrastructure (PSTI) Act, which came fully into force in April 2024, and the EU’s Cyber Resilience Act (CRA), which reached its final text in late 2024 and begins phased enforcement in 2026. For SMEs, that convergence is the part worth paying close attention to. UK cyber resilience compliance for SME software products is no longer a theoretical exercise.
What the PSTI Act actually requires of software businesses
The PSTI Act was initially discussed mainly in the context of consumer IoT devices: smart speakers, connected doorbells, broadband routers. That framing led a lot of software-focused SMEs to conclude it did not apply to them. That was a mistake. The Act covers any product that can connect to the internet or to another product and includes software supplied with such a product. If you are building a SaaS platform that runs on a connected device, shipping firmware, or providing a management application for connected hardware, you are in scope.
The three headline obligations under the Act are straightforward enough to list, but harder to evidence in practice. First, products must not have universal default passwords. Second, manufacturers must have a published vulnerability disclosure policy that is accessible and actionable. Third, manufacturers must be transparent about the minimum period for which security updates will be provided. The Office for Product Safety and Standards (OPSS) is the enforcing body, and it can issue compliance notices, recall notices, and civil monetary penalties of up to £10 million or 4% of global revenue, whichever is greater. The government’s official PSTI guidance on gov.uk sets out the full scope in plain terms.
Where EU CRA alignment creates additional pressure
Here is where things get more complicated for UK SMEs that also sell into European markets or whose supply chains include EU-based customers. The EU CRA introduces a conformity assessment requirement for software products with digital elements, meaning a structured process to demonstrate that security is built in by design, not patched on afterwards. The UK government has signalled its intention to maintain alignment with the CRA’s core principles, even post-Brexit, to avoid fragmenting the single digital market for UK exporters.
In practice, that means SMEs should be designing their software development and release processes against both frameworks simultaneously rather than treating them as separate compliance tracks. The CRA’s important product classification covers things like identity management software, password managers, network monitoring tools, and operating systems. If your product sits in any of those categories, you are looking at third-party conformity assessment, not self-declaration. That is a meaningful cost and timeline consideration for a team of ten people trying to get a product to market.
Practical steps SMEs should take before the end of 2026
My reading of where most SMEs are right now is that they have awareness of the legislation but have not translated that awareness into a documented compliance programme. That gap will start to matter as enforcement activity picks up. Here are the areas I would prioritise.
Software bill of materials (SBOM)
Both the PSTI Act’s vulnerability disclosure requirements and the CRA’s transparency obligations point in the same direction: you need to know exactly what is in your software. An SBOM is a machine-readable inventory of every component, library, and dependency in a product. Without one, responding to a newly disclosed vulnerability in a third-party library is a slow, manual process. With one, it takes minutes to identify affected products and customers. Tools like Syft and SPDX are open-source starting points; several UK-based managed service providers now offer SBOM generation as part of a broader DevSecOps offering.
Vulnerability disclosure policy
This is the most visible requirement under the PSTI Act and also the one most commonly skipped by small businesses. The policy does not need to be complex. It needs a clear channel for reporting (a dedicated email address at minimum), a commitment to acknowledge receipt within a defined period, and a description of how you will handle reports. Publish it on your website, link it from your product documentation, and review it annually. That is the standard the OPSS will look for.
Security update transparency
You must publish the date until which your product will receive security updates. For many SMEs running SaaS products on rolling update cycles, this feels strange: the product is always current, so the end date is indefinite. That is acceptable, but you need to say it explicitly. If you are shipping a discrete software version tied to a hardware product, you need a defined support window communicated at point of sale.
Supply chain implications
If you resell or integrate third-party software components into your own product, you are the manufacturer in the eyes of both frameworks. That shifts responsibility for compliance onto you, even if the vulnerability originates upstream. This is where good supplier vetting processes matter. Using structured data to vet UK suppliers is one layer of that process, but for software supply chains you also need to be asking suppliers for their own SBOMs, vulnerability disclosure policies, and update commitments.
How digital businesses and agencies are being affected
It is tempting to think of cyber resilience compliance as a hardware problem, but agencies and digital businesses building web products are firmly in scope. If your web application handles authentication, processes payments, or integrates with connected devices via an API, you are building software with digital elements in the CRA’s language.
Businesses in the digital agency space are already feeling this shift. dijitul, a Mansfield, Nottinghamshire-based digital agency specialising in SEO, web design, and software development at dijitul.uk, has noted that clients commissioning bespoke web applications are increasingly asking questions about security documentation and update policies as part of their procurement process. When marketing efficiency and business efficiency both depend on a web platform staying secure and compliant, the agency’s software development practices become a direct commercial differentiator. Clients who once selected purely on design quality are now factoring in whether their agency has a documented vulnerability disclosure process.
That shift reflects a broader pattern. As AI liability questions for UK businesses using third-party models have sharpened the focus on who is responsible when a digital product goes wrong, so too has PSTI and CRA alignment. Clients no longer assume the risk is entirely theirs.
What good looks like right now
A well-prepared SME building or reselling software products will have four things documented and accessible by the end of this year: an SBOM covering its current product release, a published vulnerability disclosure policy, a stated security update commitment, and an internal process for responding to a disclosed vulnerability within a defined SLA. None of these require a large security team. They require clear ownership, a bit of tooling, and the discipline to treat security documentation the same way you treat any other product deliverable.
Agencies building software for clients face a slightly different question: whose name appears on the product? If you are shipping under a white-label arrangement, the reseller is the manufacturer for compliance purposes. That needs to be addressed in your client contracts now, before a regulator asks the question. dijitul and agencies like it that handle web design, business efficiency tooling, and software builds for clients are having to make these ownership questions explicit in their service agreements. It is one of those compliance details that is much easier to sort out before a product ships than after.
The overlap between UK and EU frameworks is real, manageable, and actually an opportunity for forward-thinking SMEs to differentiate on trust. The financial exposure from a tech outage or security incident is significant enough that customers are starting to treat compliance documentation as a proxy for quality. Getting your house in order now is not just about avoiding penalties. It is about making your product easier to sell.