Ten weeks after the American executive order on cybersecurity was signed, the machinery behind it has started producing documents, and the documents are more consequential than the order itself. Eleven days ago the minimum elements of a software bill of materials were published: the specific data fields a supplier must provide, the machine-readable formats that qualify, and the practices governing how often it is generated and how it reaches the buyer. Late last month brought an official definition of which software counts as critical, followed within a fortnight by the security measures that apply to it and by minimum standards for how vendors must test their own code. Agency deadlines are now falling due in sequence. Running alongside it, this week's coordinated attribution of the mass exploitation of enterprise mail servers to a state intelligence service — announced jointly by the United States, the European Union, NATO, the United Kingdom and Japan — keeps the political weather exactly where the order's authors want it. For a company with no American government business, the natural response is to stop reading. That would be a mistake, because this is not really a cybersecurity policy. It is a procurement policy, and procurement policy travels.
Regulation by purchasing
Washington cannot easily legislate how software is built. It can decide what it buys, and it is the largest software buyer on earth. The order therefore works through the acquisition system: requirements are defined, then written into federal acquisition rules, then into contracts, then flowed down to subcontractors. A vendor that wants to keep the account complies. And because software vendors do not maintain a separate, better-governed product line for one customer, the properties demanded by that customer propagate to every customer — including yours. That is the mechanism by which a domestic purchasing rule becomes a global commercial baseline, and it moves considerably faster than legislation. The last time this happened at scale, it was accessibility requirements in federal procurement quietly reshaping the interface standards of an entire industry. The practical forecast: within eighteen to twenty-four months, bills of materials, secure development attestations and defined logging baselines stop being federal artefacts and start appearing as standard terms in ordinary enterprise contracts, insurance questionnaires and tender evaluations, in markets that have never heard of the order that created them.
What is actually in it, in four buckets
Strip out the machinery of government and the order asks for four things that any organisation can read as a checklist. Producer practices. Software suppliers must use secure, separated build environments, maintain provenance data for internal and third-party components, run automated vulnerability checking with remediation, and operate a vulnerability disclosure programme. Conformance is asserted through self-attestation rather than third-party audit. Artefacts. A bill of materials meeting the published minimum elements: supplier, component name, version, unique identifiers, dependency relationships, who compiled the data and when — in one of the recognised machine-readable formats, refreshed on a defined cadence, with declared known unknowns rather than silent gaps. Buyer-side operational baselines. Multi-factor authentication and encryption for data at rest and in transit, endpoint detection and response deployed across the estate, a zero trust architecture programme with dates, and — the quiet one — defined requirements for what events are logged and for how long those logs are kept. Institutional capability. A standardised incident response playbook so that every response does not start from improvisation, a review board to investigate significant incidents and publish findings, and mechanisms to remove contractual barriers to threat information sharing. A private company can adopt all four without a single reference to American law.
The most copyable requirement is the least discussed
Of everything in the order, the logging provisions are the item I would lift first. They exist because investigation after investigation stalled for the same reason: by the time anyone knew to look, the evidence had aged out. The government's answer is to specify centrally which event types must be captured, how they must be retained and for how long, so that the answer does not depend on each agency's budget cycle. The detailed retention standard is still being finalised, but the direction is clear, and it is roughly a year of readily searchable logs with a longer cold tail. Most mid-sized commercial organisations retain thirty to ninety days because that is what the licence bundle included. The dwell times in the past year's significant intrusions were measured in months. The mismatch is the whole problem, and closing it costs storage and attention rather than a transformation programme.
Attestation shifts liability, not risk
It is worth being clear-eyed about the weakest link in the design. Conformance is largely self-attested. A supplier signs a document saying its development practices meet the standard, and the buyer relies on that signature. This does not verify anything. What it does is move liability: a false attestation from a named officer is a different legal object from marketing copy, and it creates a document that is discoverable after an incident. For a commercial buyer, the transferable lesson is small and useful — ask for the attestation, ask who signs it, and keep the copy. A vendor that will describe its practices in a sales meeting but not sign a statement about them has told you something.
Practical Guidance for Compliance Alignment Review
- Adopt the vocabulary rather than inventing your own. The published definitions of bill of materials elements, critical software and secure development practices are free, precise, and about to be industry-standard.
- Map your current state against the four buckets and record the gaps with owners and dates, not with a maturity score.
- Fix logging first. Define source systems, event types and retention, then confirm the logs are searchable under pressure.
- Identify your own flow-down exposure. If you sell software or services to anyone who sells to the American government, these terms reach you through the chain, probably at the next renewal.
- Prepare your attestation before a customer requests it, including the honest list of what you do not yet do.
- Ask suppliers for the artefacts they already produce for other regulated buyers, and put the request in the contract rather than the meeting.
- Ignore products marketed as compliant with the order. No product confers conformance; practices and evidence do.
- Set a review date in twelve months, because the rules that matter commercially are still being drafted.
The Regional Angle
Three consequences are specific to this market, and the first is a timing advantage. Gulf regulators are, by design, importers and adapters of external frameworks. National cybersecurity controls in the region draw heavily on American standards, often with recognisable structure and sometimes with near-identical control language, then add local requirements on top. There is no serious reason to expect this to be different: software supply chain requirements, bills of materials, secure development expectations and logging baselines will appear in regional national frameworks and critical infrastructure rules within a couple of years, and — because government and government-related entities are the dominant enterprise buyers here — they will appear in tenders before they appear in law. The advantage is that the future requirement is readable today, in English, for free. Organisations that sell to the public sector in this region should be building the artefacts now, on their own timetable, rather than in the eight weeks between a tender's publication and its submission deadline. The second is a problem the global commentary does not see, because it does not exist in the markets where the commentary is written. Enterprise software here is very often a global product plus locally built extensions: Arabic interfaces and documents, VAT and e-invoicing logic, wage protection file formats, gratuity and leave calculations, statutory reports, customs and free zone specifics. Those modules are software. They are also, in a large number of cases, built by a local partner with no source control discipline worth the name, no separated build environment, no code signing, no dependency inventory, and no vulnerability disclosure route — with the deployed version sometimes differing from anything in a repository. When the bill of materials requirement arrives, the global vendor will comply comfortably and the local extension will be a blank page, sitting inside the same system and usually with more privileged database access than any component the vendor shipped. Any serious alignment review in this region has to cover partner-built code, and the first three questions are where the source lives, who can change it, and whether the running version can be rebuilt from that source. The third is about how requirements are written into regional tenders, where compliance tables carry real evaluation weight. Adding "bidder shall provide an SBOM" to a technical requirements matrix without specifying the format, the refresh cadence, the treatment of known unknowns and the named person who will actually review it produces exactly what such clauses always produce here: a yes in a box, a PDF nobody opens, and no change in risk. If the artefact is worth requesting, it needs an evaluator, a scoring basis and a place in the ongoing contract rather than the bid pack — and the same discipline applies to the incident notification timelines that regional sector regulators and national response teams increasingly expect alongside them.
The objection worth taking seriously
The strongest objection is parochialism. This is one country's purchasing policy, driven by one country's politics and one country's incidents. Europe is legislating its own approach to network security obligations and is openly discussing mandatory product security requirements with a different structure, different definitions and different enforcement. A Gulf or Asian company that reorganises its assurance programme around American definitions today may find itself re-documenting everything against a European scheme in two years, then again against a regional framework — three sets of paperwork describing the same controls, none of which makes anything materially safer. That risk is real, and anyone who has watched a compliance function multiply its output while the security posture stays flat should take it seriously. The defence is to separate the engineering from the paperwork. Underneath every one of these regimes sits the same short list: know what your software is made of, control who can change what you ship, patch on a defined clock, authenticate strongly, detect on the endpoint, keep logs long enough to investigate, and be able to describe your practices honestly to a buyer. That list does not change when the jurisdiction does. Build the capability once and treat each regime's documents as renderings of it — different formats, same underlying data. The organisations that will suffer the triple burden are the ones that build to the document rather than to the capability, which is the same mistake that made the last two decades of certification largely decorative.
Common Questions
Does this apply to us if we have no US government business?
Not legally. Commercially, it reaches you twice: through vendors who standardise their product on the strictest customer, and through customers who flow the terms down the chain. The second route arrives at your next renewal.
Is a bill of materials useful if we only buy commercial software?
Yes, for one specific job: knowing within hours, rather than weeks, whether a newly announced component vulnerability is present in something you run. That is an operational capability, not a paperwork exercise.
What should we do first?
Logging retention and multi-factor authentication coverage. They are the two items in the order with the clearest evidence behind them and the lowest dependency on anybody else's roadmap.
What should we expect over the next twelve months?
Expect detailed budget office direction on logging retention and zero trust milestones within months, with specific timeframes agencies will partly miss. Expect the acquisition rulemaking that converts all of this into contract clauses to take twelve to twenty-four months, which puts the real commercial inflection in 2023 rather than now. Expect European legislators to advance their own product security requirements, creating a second regime with different artefacts and the same engineering underneath. Expect bills of materials to appear in ordinary commercial contracts and insurer questionnaires before they are mandatory anywhere. And expect the new review board to be stood up and to publish on a major incident — at which point the findings, not the order, become the thing procurement teams actually quote.
Compliance Alignment Review — we map your controls and your suppliers against the emerging supply chain, logging and attestation expectations, including the partner-built code that no framework remembers to ask about.