Consider an illustrative Nairobi product team that distributes an inventory-management application to European customers. A library used in the installed software has a serious vulnerability, but the team cannot immediately say which release contained the component, which clients are affected, whether an exploit has been observed, or who can authorise an emergency update. The code can be patched. The harder problem is organisational: the evidence and response path needed to act safely were never designed into the product.
That scenario is becoming commercially material. The EU Cyber Resilience Act (CRA) entered into force on 10 December 2024. Article 71 of the CRA sets the main application date at 11 December 2027, with manufacturers’ Article 14 reporting obligations applying from 11 September 2026. These are different stages, not one present obligation. The Act reaches in-scope products with digital elements made available on the EU market; location of the engineering team is not the decisive question. African firms supplying such software or connected products need a repeatable way to know what they shipped, maintain it, and respond when its security changes.
A release creates a responsibility that lasts
The CRA’s forthcoming main requirements address software and hardware products with digital elements across planning, design, development and maintenance. That lifecycle framing matters because many software teams still treat launch as the point at which security work tapers off. In practice, a release creates a maintenance commitment: dependencies age, configurations drift, credentials leak, and newly discovered vulnerabilities alter the risk of a product already in use.
The regulation does not make every African technology company automatically subject to EU law. Articles 2–3 and recitals 11–12 of the CRA distinguish products with digital elements and qualifying remote data-processing solutions from general websites or cloud services. Remote processing qualifies when it is designed by, or under the responsibility of, the manufacturer and its absence would prevent a product function. A customer portal or standalone SaaS offering is therefore not automatically covered. Product characteristics, market placement and exclusions require their own analysis. Yet the operational lesson is wider than the legal perimeter: a supplier needs to identify a vulnerable component, judge affected versions, notify the right people and issue a verified fix.
This is why compliance cannot be left to a final document review. A technical file assembled at the end of a project cannot reconstruct decisions that were never recorded: security requirements, third-party components, component versions, known limitations, release approvals and the ownership of post-release maintenance.
The useful unit is the product, not the repository
A source-code repository is not a product record. It rarely captures the full operational boundary: deployed services, mobile releases, container images, configuration, managed cloud services, identity providers, third-party APIs, documentation, support channels and contractual promises. A product record does.
Composition. Maintain an accurate component record for each released version. Annex I, Part II of the CRA requires a commonly used, machine-readable software bill of materials covering at least top-level dependencies when the main obligations apply. The aim is not paperwork. It is rapid impact analysis when a dependency, framework or build tool becomes a concern. Track material transitive dependencies where feasible as well, with versions, licence status, provenance and the product versions in which they are used.
Decision history. Retain the security requirements and risk decisions that shaped the release. Where a team accepts a residual risk, substitutes a control, delays a fix or relies on a cloud provider, that judgement should have an owner and an expiry or review point. This prevents a departure from best practice becoming an anonymous permanent feature.
Service boundary. Document what the supplier can update and what the customer, platform host or integration partner controls. A qualifying remote component may permit a rapid server-side patch; an offline-capable mobile product may need a staged client update; a deployment in a ministry’s environment may depend on an internal operations team. These are different response models and should not be promised as if they were identical. The operational inventory may include services that are outside the CRA’s legal product boundary.
The NIST Secure Software Development Framework is useful here as an outcome-oriented reference rather than a universal checklist. It groups practice around preparing the organisation, protecting software, producing well-secured software and responding to vulnerabilities. NIST explicitly frames its use as risk-based, taking account of cost, feasibility, applicability and the dependencies between foundational practices. That is a more realistic starting point for teams with small security functions than an attempt to reproduce the controls of a global platform company.
Evidence must survive a handover
African software delivery often involves distributed realities: a product owner in Kampala, a contracted development partner elsewhere, a cloud account held by an overseas funder, and a customer support desk that hears about incidents first. That arrangement can produce excellent work, but it makes ownership gaps unusually expensive.
A buyer should be able to identify who owns the product security contact, the supported versions, update channels, dependency record, incident decision authority and end-of-support policy. Those items should survive a staff departure, procurement transition or donor-funded project close. They should be held in systems the operating organisation controls, not only in a vendor’s inbox or a departing engineer’s laptop.
This does not require publishing sensitive architecture diagrams or exposing every dependency to every customer. It requires an internal record with controlled access, and a customer-facing way to communicate support conditions, advisories and updates. The distinction protects both security and accountability.
For products that include generative AI, the boundary expands further. NIST’s final SP 800-218A community profile augments the SSDF with practices specific to AI model development and AI systems that use those models. It is guidance, not a binding product rule. Still, it highlights a practical point: model selection, training or fine-tuning data, prompts, retrieval sources and tool integrations can create security-relevant dependencies just as conventional packages do. An AI feature cannot be treated as a black box purchased outside the software lifecycle.
Reporting clocks expose weak operating models
The CRA’s reporting timetable is demanding but has defined triggers. Article 14 concerns an actively exploited vulnerability contained in the product or a severe incident affecting its security, not every serious library flaw or general corporate breach. Severity includes harm, or possible harm, to the protection of sensitive or important data or functions, and actual or possible introduction or execution of malicious code. Manufacturers must report without undue delay, with an early warning no later than 24 hours after awareness and a notification no later than 72 hours. The final vulnerability report is due within 14 days after a corrective or mitigating measure becomes available; the severe-incident final report is due within one month after the incident notification.
ENISA’s Single Reporting Platform is the reporting route. Article 16 assigns its establishment and day-to-day operation to ENISA; the Commission’s reporting guidance confirms that it became operational on 11 September 2026. Notifications go to the designated coordinating Computer Security Incident Response Team (CSIRT) and ENISA, subject to statutory safeguards governing dissemination. For manufacturers without a main EU establishment, Article 14(7) selects the CSIRT endpoint through an ordered test involving the authorised representative, importer, distributor and, finally, location of the highest number of users. Teams should determine that route before an incident, rather than simply choose the customer’s country. These clocks are not generic breach-notification targets to copy into a policy: someone must assess the trigger, preserve evidence and authorise technically honest communications.
A lightweight incident rehearsal is more valuable than a beautifully written procedure that no one has used. Choose one plausible event: a known vulnerability in a widely used dependency, a compromised deployment credential or a malicious package update. Time how long it takes to identify affected product versions, establish the customer and market footprint, decide immediate containment, prepare a technically honest notice and release a tested remediation. Record the gaps. Repeat after the next major architectural change.
Open source needs stewardship, not suspicion
Open source is foundational to modern software and can reduce cost, speed local adaptation and avoid unnecessary platform lock-in. The answer to supply-chain risk is not to ban it or to force every team to rebuild well-maintained components. It is to know what is being relied on, choose projects with credible maintenance signals, constrain unnecessary dependencies and plan what happens when a maintainer disappears or a critical flaw is disclosed.
The CRA recognises a distinct position for free and open-source software. Non-commercial open-source activity should not be confused with placing a commercial product on the market. Article 24 sets duties for legally defined open-source software stewards, including particular reporting duties from 11 December 2027: actively exploited vulnerabilities where they are involved in product development, and certain severe incidents affecting the development infrastructure they provide. That does not remove responsibility from a company integrating components into its own in-scope commercial product. A firm can respect the volunteer-maintained ecosystem while owning the security of what it supplies.
For public-sector or development programmes, procurement should fund this work explicitly. A contract priced only for features creates predictable pressure to defer dependency updates, release engineering, documentation and support. Buyers should ask for a support horizon, update process, component visibility appropriate to the risk, escalation contacts and handover rights. These are delivery requirements, not optional extras added after a cyber incident.
Build the smallest credible control loop
A credible starting point is modest but specific. Map each live product to an accountable owner and a support commitment. Establish a release record that links deployed versions to their material components and environments. Put a monitored security contact and vulnerability intake route in place. Then rehearse one response path with engineering, support and leadership together.
Xelius helps organisations map product boundaries, data flows, supplier dependencies and operating responsibilities, then turn the findings into maintainable platform and delivery practices. For firms exposed to European customers, this work should begin well before a conformity review: the underlying evidence takes time to create through real releases.
The commercial value of secure software will increasingly be judged after a vulnerability is found, not only during a sales demonstration. Teams that can see their product clearly, make a disciplined decision and deliver a trustworthy update will be better placed to retain customers, negotiate mature contracts and build software that remains useful beyond its initial launch.
