Cyber Resilience by Design: What Display Vendors Should Now Expect From Their Software Vendors

The EU Cyber Resilience Act is changing the relationship between hardware manufacturers and the software suppliers embedded inside their products. For display vendor product managers, the challenge is no longer simply whether third-party software performs well. It is whether the vendor behind it can provide the security processes, evidence and lifecycle commitments needed to support the display vendor's own regulatory obligations.

For years, software embedded inside interactive displays, meeting-room devices and collaboration hardware has largely been assessed through familiar product-management criteria: functionality, compatibility, performance, user experience and commercial fit.

Cybersecurity has always mattered, but in many vendor relationships it has been treated as a technical assurance exercise rather than a core element of product governance.

The EU Cyber Resilience Act changes that balance.

Under the CRA, manufacturers placing products with digital elements on the EU market face obligations around cybersecurity, vulnerability handling, documentation, support periods and incident reporting. For a display vendor whose brand appears on the finished product, those obligations do not stop at the boundary between hardware developed internally and software licensed from a third party. The software integrated into the product becomes part of the wider compliance picture, and the Regulation says so explicitly: Article 13(5) requires manufacturers to exercise due diligence when integrating components sourced from third parties, so that those components do not compromise the cybersecurity of the product.

That creates a practical challenge for product managers.

A display vendor may control the product roadmap, hardware architecture and market launch, yet depend on several external software vendors for collaboration, wireless sharing, device management or other embedded capabilities. If one of those components develops a security problem, the display vendor needs to know quickly what is affected, which product versions contain it, what mitigations are available and how the vulnerability will be resolved.

In other words, cyber resilience is becoming a supply-chain capability.

The question display vendor product teams need to ask is therefore changing. It is no longer simply: Is this software secure?

It is: Can this supplier help us prove that our product remains secure throughout its commercial life?

CRA turns supplier cybersecurity into a product-management issue.

The Cyber Resilience Act is significant partly because it treats cybersecurity as something that has to be managed across the lifecycle of a product rather than considered only at the point of release.

For display vendors, that makes third-party software relationships particularly important.

At DisplayNote we find that two practical questions determine much of a display vendor's exposure, and both come straight from the Regulation's definition of a manufacturer (Article 3(13)): whose name or trademark the product is marketed under, and what third-party software sits inside it. Where a display vendor commissions or integrates software and markets the finished device under its own brand, the distinction between "our code" and "their code" becomes much less useful when assessing responsibility for the complete product.

That does not mean every product manager needs to become a regulatory lawyer. It does mean that cybersecurity maturity needs to become part of supplier evaluation in the same way as technical capability, roadmap fit and commercial stability.

A product team should be able to answer relatively simple operational questions. Who do we contact if this component develops a vulnerability? How quickly will the supplier tell us? Which of our products contain the affected version? How long will that version be supported? Can the supplier provide the evidence we need for our own technical documentation?

If those answers are unclear, the problem is not confined to the software vendor. It becomes part of the display vendor's own product risk.

The regulatory clock is already moving.

For product teams, the CRA should not be treated as a December 2027 project.

The legislation introduces obligations in stages. From 11 September 2026 the Article 14 reporting obligations apply: an actively exploited vulnerability or a severe incident affecting the product must be notified to the manufacturer's national CSIRT and to ENISA, with an early warning within 24 hours of becoming aware of it, a fuller notification within 72 hours and a final report within 14 days (one month for incidents). Unlike the rest of the Regulation, this applies to products already on the market, not only to new releases (Article 69(3)). The broader essential cybersecurity requirements, technical documentation and conformity assessment apply from 11 December 2027.

This sequencing matters because incident readiness comes before the wider compliance deadline.

If a vulnerability affecting an integrated software component becomes actively exploited, the display vendor may need information from its supplier quickly enough to support its own reporting and response process. That means organisations cannot wait until late 2027 to decide how supplier notification, escalation and technical evidence will work.

The practical work starts earlier: establishing security contacts, confirming notification paths, building version traceability and understanding whether software vendors are capable of supporting the obligations that will increasingly sit around the product.

For product managers, this is as much an operating-model question as a regulatory one.

The software supply chain becomes part of the product's security posture.

Modern display products are rarely self-contained.

An interactive display or collaboration device may include an operating system, device-management software, wireless sharing tools, conferencing applications and other licensed components. Some may be developed internally, while others come from specialist software suppliers.

From a product perspective, that modularity is attractive. Display vendors can combine proven technologies, accelerate development and focus investment where they create the most differentiation.

The downside is dependency.

When a vulnerability is discovered in a third-party component, the display vendor needs to understand whether the affected version exists anywhere in its product range. That sounds simple until several firmware generations, product variants and regional SKUs are involved.

A supplier that cannot identify which software versions have been delivered, or a display vendor that cannot map those versions back to its own firmware releases, creates a basic traceability problem.

That problem becomes much more serious during a live security incident.

The ability to answer "Are we affected?" quickly may depend on records that were created months or years earlier. Product teams therefore need to think about software version management as part of cyber resilience rather than simply release administration.

At DisplayNote we advocate maintaining a current 'build register' linking vendor software versions to the display vendor's firmware releases.

That may sound mundane compared with more sophisticated cybersecurity controls, but during an incident it can become one of the most valuable records the organisation owns.

Five capabilities display vendors should expect from software vendors.

The CRA contains substantial regulatory detail, but product managers do not need to reproduce the legislation in their supplier assessments.

A more useful approach is to focus on the operational capabilities that indicate whether a software vendor is likely to support a resilient product lifecycle.

1) A functioning vulnerability-response process

Every embedded software supplier should have a clear and monitored route for security communication.

A generic contact form is not the same thing as a security process. Display vendors should know who receives vulnerability notifications, how issues are triaged and how their own security team will be informed if a problem affects software integrated into their products.

The question is not simply whether an email address exists. It is whether the supplier has an escalation process behind it.

This becomes especially important when an actively exploited vulnerability is involved and the display vendor's own 24-hour reporting clock may depend on information arriving quickly from further down the supply chain.

2) Version and build traceability

A mature supplier should be able to state which versions of its software have been provided and what changes exist between releases.

The display vendor should then be able to map those versions to its own products and firmware builds.

Without that relationship, vulnerability management becomes guesswork. A security advisory may identify an affected software version, but neither party can immediately establish which products in the field contain it.

Version traceability is therefore more than release hygiene. It is part of incident readiness.

3) A credible vulnerability-disclosure model

Researchers need a clear way to report security issues.

A published vulnerability disclosure policy demonstrates that the vendor has considered what happens when an external researcher identifies a flaw, how information is handled and how disclosure is coordinated. Under the CRA a coordinated vulnerability disclosure policy is a manufacturer obligation in its own right (Annex I, Part II(5)), so a vendor that also sells its software standalone in the EU should already have one, or a dated plan to publish one.

For a display vendor, this matters because the first warning about an embedded vulnerability should ideally come through a managed security process rather than appearing unexpectedly in a public forum.

At DisplayNote, we typically treat the absence of a vulnerability disclosure process, or even a credible roadmap towards one, as a warning sign during vendor assessment.

4) Software-component transparency

Software Bill of Materials (SBOM) requirements are pushing component visibility much further into mainstream product governance.

One nuance is worth knowing before the supplier conversation. The CRA requires each manufacturer to draw up a machine-readable SBOM covering at least the top-level dependencies of its product (Annex I, Part II(1)) and to provide it to market surveillance authorities on request. It does not oblige a software supplier to hand its SBOM to a customer. A display vendor that needs component information from its vendors in order to build its own SBOM has to secure that contractually, which is exactly why it belongs in supplier due diligence rather than in a last-minute documentation request.

For display vendor product teams, the value of an SBOM is practical. It creates a structured view of what sits inside a release, helping organisations assess exposure when a component vulnerability emerges.

The question to suppliers should not be framed simply as "Do you have an SBOM?" but as "Can you provide release-level component information in a usable format, and how will that process be maintained as the software evolves?"

5) Defined support and update commitments

One of the easiest risks to overlook is lifecycle mismatch.

A display vendor may expect to support a product for several years, while a software supplier may have a much shorter commercial horizon for the component integrated into it.

If those timelines are not aligned, the display vendor can find itself committed to maintaining a product whose embedded software no longer receives security support.

That is why support periods need to be explicit.

The CRA makes this the display vendor's problem directly. As manufacturer of the finished product, the display vendor determines its support period, which is expected to be at least five years unless the product is clearly intended for shorter use, and it may take the support periods of integrated components into account when doing so (Article 13(8)). A supplier's commitment is therefore an input to the display vendor's own published support period, not a substitute for it. Security updates issued during that period must also remain available for at least ten years after issue, or for the remainder of the support period if longer (Article 13(9)), which is a further reason to know how long a supplier will keep its builds available and reproducible.

Product managers should understand how long each supplier will maintain relevant versions, how security updates will be provided and how changes in support status will be communicated.

A vague promise that software will be "supported" is no longer enough. The commitment needs to be specific enough for the display vendor to build its own lifecycle plan around it.

The 24-hour clock changes the supplier relationship.

One of the most consequential changes for display vendors is the speed at which security information may need to move. That creates a dependency on suppliers that may not have existed formally before.

Two points of nuance matter here. First, the 24-hour clock in Article 14 belongs to the manufacturer and runs from the moment the manufacturer becomes aware of the issue; it is a deadline to report to the CSIRT and ENISA, not a deadline to fix. Second, the Regulation imposes no statutory notification deadline from a software supplier to its display vendor customer. Whatever the display vendor needs from its vendors in those first hours has to be agreed in the contract, measured from the supplier's own awareness.

If a collaboration software vendor discovers an actively exploited vulnerability at 9am, the display vendor cannot afford to learn about it several days later through an informal account-management conversation. Security communication needs a different path from normal commercial communication.

Product teams should therefore establish two-way security contacts before an incident occurs. The supplier should know who to notify at the display vendor, while the display vendor should know which security function owns escalation at the supplier. The reverse direction is also a CRA expectation: a manufacturer that identifies a vulnerability in a component it integrates is required to report it to the person or entity maintaining that component (Article 13(6)).

That process should also define the minimum information required: affected versions, whether and how the vulnerability is exploitable in the display vendor's specific integration, known exploitation, available mitigations, expected remediation and any action the display vendor should take immediately. Exploitability in the display vendor's own product matters more than it might seem: the Commission's guidance on the CRA (July 2026) makes clear that a manufacturer reports what is actively exploited in its own product, so a supplier notification that only says "there is a vulnerability" leaves the display vendor unable to make the determination it is actually required to make.

In practice, incident readiness is not created during an incident. It is created by the quality of the supplier relationship beforehand.

SBOMs are becoming operational infrastructure.

SBOMs can easily be dismissed as another documentation requirement, particularly by product teams already managing extensive technical documentation and conformity-assessment processes.

That understates their operational value.

Imagine a vulnerability is discovered in a widely used open-source component. The first question facing a display vendor is whether that component exists anywhere in its product portfolio.

Without structured component visibility, answering that question can involve emails between engineering teams, source-code searches and manual investigation across several product generations. By the time the organisation has established its exposure, valuable response time may already have been lost.

A maintained SBOM changes that conversation.

It does not remove the vulnerability, nor does it replace security testing, but it gives the organisation a much clearer starting point for assessing exposure.

For product managers, that means SBOM readiness should be treated as a supplier capability rather than a document to request once before conformity assessment. The useful question is whether the vendor can generate and maintain the information consistently with each relevant release.

That is the difference between compliance paperwork and operational resilience.

Product support periods need to align across the supply chain.

Product lifecycle planning is another area where CRA preparation exposes previously hidden dependencies.

Display manufacturers often think in multi-year commercial cycles. A product may remain in use well beyond its initial launch, particularly in enterprise and education environments where hardware estates are refreshed gradually.

Embedded software suppliers may operate differently.

A vendor may discontinue a release, move customers to a new architecture or change its support model while the display vendor still has thousands of devices in the field.

If support commitments have not been established in advance, the display vendor may face an uncomfortable choice between maintaining unsupported software, engineering a late-stage replacement or accelerating the end of support for its own product.

None is attractive.

Product managers should therefore treat software support periods as part of commercial and technical due diligence. The supplier's lifecycle needs to be compatible with the lifecycle the display vendor intends to promise its customers.

Security updates, maintenance commitments and end-of-support dates should all be clear enough to support that planning.

The CRA is accelerating this conversation, but the underlying principle is simply good product governance.

What mature vendor due diligence looks like.

The strongest supplier conversations are not the ones where every vendor answers "yes" to a checklist. They are the ones where the vendor can provide evidence quickly and explain how its processes work in practice.

A useful assessment might look like this:

Red flags product managers should not ignore.

Most product managers are used to balancing risk. No supplier will be perfect, and emerging regulatory requirements mean some capabilities will still be developing across the industry.

The important distinction is between a capability that is on a credible roadmap and one that has not been considered.

Several warning signs deserve particular attention. A supplier that cannot identify a named security contact, cannot confirm which versions are deployed or has no vulnerability disclosure process introduces obvious dependencies into the display vendor's own readiness. The same applies where SBOM requests are dismissed without explanation, support periods are undefined or incident-response responsibilities remain unclear.

These issues should not automatically end a commercial relationship, but they should change the risk conversation.

Product managers need to understand what has to improve, by when, and whether commitments can be documented contractually.

The most dangerous answer is not necessarily "we are not ready yet". It is "we have not thought about it".

Compliance should influence supplier selection before conformity assessment begins.

The Cyber Resilience Act will inevitably generate a great deal of legal interpretation, technical documentation and conformity-assessment activity over the coming years.

For display vendor product managers, however, one of its most immediate consequences is much simpler: cybersecurity maturity becomes part of supplier quality.

Software vendors are no longer being assessed only on whether their products integrate well, deliver the right functionality and support the commercial roadmap. Their ability to communicate incidents, maintain release visibility, support vulnerability management and provide lifecycle evidence increasingly affects the display vendor's own risk position.

That should influence vendor selection now, not just when a technical file is being assembled.

The organisations best prepared for the CRA are unlikely to be those that begin collecting evidence at the last possible moment. They will be those that already understand which components sit inside their products, which suppliers can support them properly and where dependencies still need to be strengthened.

For display vendors, cyber resilience is therefore becoming a product-management discipline as much as a security discipline.

The legislation may provide the catalyst, but the principle is broader.

If someone else's software ships inside your product, their cybersecurity readiness increasingly becomes part of your product promise.

A practical next step.

How confident are you in the cyber readiness of the software vendors inside your product? DisplayNote is a CRA manufacturer in its own right for Montage and Launcher, so we are building the capabilities described here for our own products first: our Article 14 reporting capability is in place for 11 September 2026, and we work with display vendor partners to provide a named security contact and escalation owner, software-version traceability, and dated commitments for a published vulnerability disclosure policy, release-level SBOMs and defined support periods.

Our CRA Software Vendor Readiness Check is designed to help display vendor product teams ask the same practical questions of every software supplier they evaluate.

This article is intended as practical product-management guidance and does not constitute legal advice. Organisations should refer to the Cyber Resilience Act and appropriate legal or regulatory advisers when determining their specific obligations.