A CVE in a widely used component goes to actively exploited on a Tuesday morning. By early afternoon, your three largest customers have all emailed the same question, and your answer window is measured in hours. What they want to know is not whether you saw the headline. They want to know which products they bought from you contain that component, and whether you can prove it under a deadline.
That scenario, not a regulator’s fine, is what product security in manufacturing is built to survive. You ship software inside physical products, you support what you shipped for a decade or more, and your customers now audit you the way regulators audit banks. This guide covers what the discipline involves, what actually forces investment, and what to put in place, in the order that works and survives a customer auditor.
Key Takeaways
- The sharpest forcing function in manufacturing is a customer security audit, since a failed questionnaire costs a contract faster than regulation costs a fine
- The EU Cyber Resilience Act’s Article 14 reporting obligations are live, requiring an early warning within 24 hours of learning that a shipped product’s vulnerability is actively exploited
- Answering which shipped products contain a vulnerable component depends on inventory and lineage built per build in the pipeline, months before the CVE that tests it exists
OT Security, Product Security, and Application Security Are Three Different Things
Product security protects the software inside what a manufacturer ships. OT security protects the plant where products get made. Application security is the set of practices and tooling through which product security gets delivered for the software layer. Manufacturers need all three, but they are separate obligations with separate owners, and conflating them stalls programs.
| Discipline | What it protects | Who owns it |
|---|---|---|
| OT security | The plant floor, its PLCs, SCADA systems, HMIs, robots, and sensors, with uptime and worker safety as the goals | Plant operations, funded and regulated separately from the product organization |
| Product security | The software inside shipped products, including firmware, embedded applications, companion apps, and the cloud backend | The product security organization, often under a Chief Product Security Officer |
| Application security | The practices and tooling applied to source code, dependencies, pipelines, build artifacts, and the AI tools now inside all of them | The product security or engineering organization, as the delivery mechanism |
The distinction matters because the titles are real. Manufacturers now run product security programs with named leaders, dedicated forums, and obligations that follow every product line for its supported life. That organization does not defend the plant floor, and the OT team does not answer for the firmware inside a shipped device. A program that blurs the two ends up funded by nobody, then defended by no one when an audit arrives.
Reduced to a single line, product security is the obligation, and application security is how you meet it for the software you ship. Everything else in this guide works within that frame. The software supply chain behind your products, from source through pipelines to shipped artifact, is the thing product security has to see, govern, and answer for when a customer questionnaire or a regulator’s deadline forces the question.
The Real Forcing Function Is a Customer Audit, Not a Regulator
The fastest consequence in manufacturing product security is a failed customer audit, not a regulatory penalty. Manufacturers get audited by their own customers as a condition of sale, and failing costs the contract. That pressure arrives through procurement language, lands quarterly, and applies regardless of geography, so it belongs ahead of regulation in your planning.
What customers now write into procurement
The pattern is concrete in procurement already. A large financial-services customer required a device maker to produce an export showing no critical or high vulnerabilities before it would buy. That is not an outlier demand anymore.
OEM and enterprise customers write security directly into procurement, and the requirements follow a consistent shape across industries, arriving well before any regulator asks. They repeat at every renewal, so passing once buys a year at most.
- SBOM delivery as a contract deliverable, so the customer can run your component inventory against their own vulnerability feeds
- Vulnerability disclosure SLAs and secure-development attestations, with right-to-audit clauses that let the customer verify rather than trust
- An evidence artifact on demand, a current export of open findings across the products that customer runs
The gate manufacturers build in response
Manufacturers under this pressure build an internal mirror of it. The mature version is a pre-ship gate, sometimes called a cybersecurity authorization to operate, under which a product with open critical vulnerabilities does not ship. The gate turns audit-readiness from a scramble into a standing condition, exactly the outcome the customers imposing the requirements are after. It pays for itself the first time an audit lands mid-quarter.
All of this points the program in one direction. Build it to pass a customer audit on any Tuesday and regulation mostly takes care of itself, since the audit asks for the same evidence sooner and carries the sharper penalty. Programs built the other way produce policy documents that satisfy nobody who actually buys from you. The audit is also the cheaper teacher. A failed questionnaire comes with a second chance, and a lost contract does not.
What Regulates Manufacturing Software, and What Does Not
Three external pressures matter for manufacturing software, and only one of them is law for most readers. The EU Cyber Resilience Act binds anyone placing products on the EU market, and IEC 62443-4-1 operates as market access through contracts and certification. Sector gates apply only in regulated subsegments, where precision matters more than blanket coverage.
The Cyber Resilience Act and who it binds
The EU Cyber Resilience Act is the most-cited driver among manufacturers shipping into Europe, and its reporting obligations are live. Since September 11, 2026, manufacturers must file an early warning with ENISA and their national CSIRT within 24 hours of learning that a vulnerability in a shipped product is being actively exploited. A fuller notification follows within 72 hours, and a final report is due within 14 days of a fix shipping.
The applicability test takes only one sentence. If you place products with digital elements on the EU market, the CRA applies to your existing catalogue. If you truly do not, it does not, wherever your company is headquartered. Most industrial manufacturers of meaningful size ship into Europe somewhere across their many product lines, so the geography objection rarely survives a careful look at the actual product catalogue.
Certification pressure and the US picture
IEC 62443-4-1 works differently, as market access rather than law. It defines a secure development lifecycle for industrial products, and certification to a maturity level increasingly appears in contracts as the default answer to whether your development process is secure. Certifying compels real engineering work, including static analysis, dynamic analysis, and SBOM generation, so treat it as a program driver rather than paperwork to file and forget once the certificate arrives.
The honest US federal picture is narrower than most vendor content implies. There is no federal analogue to the CRA for commercial manufacturers, and the standardized secure software development attestation requirement for federal suppliers was rescinded in early 2026 in favor of an agency-led, risk-based approach. For medical devices the FDA remains a hard gate, and aviation carries FAA and ASTM requirements, but those bind subsegments, not manufacturing as a whole.
The 24-Hour Question
When a component vulnerability goes to actively exploited, the question that decides your week is which shipped products, across which versions and branches still in the field, contain that component, and whether you can prove the answer. Everything a product security program builds either shortens the time to that answer or does not matter much.
The portfolio version of the question
It helps to notice what the question is not. Whether you are vulnerable somewhere is a question any scanner eventually answers, and nobody is asking that one. Customers and regulators instead ask the portfolio version, product by product and version by version, with a hard deadline attached. The CRA’s reporting clock and a customer’s contract SLA both start from awareness, not from readiness. A program measured against that question looks different from one measured against a dashboard.
The version-and-branch clause is the manufacturing-specific twist. You still support and patch products shipped years ago, built from branches that never merged back, on toolchains the current team may barely remember. A vertical that ships one continuously deployed service never carries this shape, and most security tooling quietly assumes that vertical rather than yours. That is how the gap forms between what your tooling reports and what your customers ask.
Why the answer stays out of reach
Most manufacturers cannot answer in time for reasons that have nothing to do with effort. SBOMs get generated at release rather than per build, for some product lines but not all, then stored as documents nobody can query across, going stale the moment a dependency moves. Each SBOM is locally true on the day it was written, and the portfolio answer your customer actually wants is still out of reach.
The structural point follows from that failure mode. This is an inventory and lineage problem, not a scanning problem, because a binary scan of one device tells you about that device, not the other forty product lines. The 24-hour clock is won in the build system, months before the CVE it will be measured against exists. Teams that internalize this stop buying scanners for an inventory problem and instrument builds instead.
Why Manufacturing Software Is Harder to Secure Than Most Portfolios
Manufacturing portfolios are harder to secure than most because of support tails, legacy infrastructure, and stack diversity rather than any shortfall in engineering discipline. Five conditions do most of the damage, each common in embedded organizations and rare elsewhere, and a program that ignores any one of them will misjudge its coverage and its costs.
Support tails and legacy infrastructure
The first condition working against you is time. A product line shipped in 2014 can still be under support today, on toolchains that no longer build cleanly, maintained by engineers who left long ago. Web portfolios retire code, while manufacturing portfolios accumulate it, and every acquired business unit brings another decade of shipped software and obligations. Nobody budgets for that tail, yet that is where audit questions concentrate, because old products run in customer environments longest.
The second condition is where the code lives. Large embedded organizations still run legacy version control alongside Git, and any tooling that only speaks Git simply cannot see that code. An inventory built on the assumption of one modern platform will report full coverage while missing entire product lines, which is worse than reporting nothing. Coverage claims deserve an audit of their own before anyone trusts a dashboard built on them.
Stack diversity and AI-generated code
The third and fourth conditions compound each other. A single product commonly spans embedded C or C++, a mobile companion app, a cloud backend, and a web console. That is four ecosystems and usually four teams under one product name. Meanwhile embedded codebases carry vendored and forked third-party code that manifest-based tooling cannot see, the most common reason a generated SBOM is wrong. That leaves one product, four ecosystems, and a component list nobody trusts.
The fifth condition is the newest of the set. AI-generated code is arriving in embedded repositories at volume, outpacing review, with little visibility into the assistants and MCP servers in use. Firmware that ships with a decade of support deserves more scrutiny than a disposable web feature, and most organizations apply less, because nothing in the pipeline distinguishes the two. That gap compounds, since code written this quarter ships inside products supported into the 2030s.
What to Put in Place, in Order
A fundable program is a sequence, not a shopping list, and the one below is ordered so each step makes the next cheaper. Each step has a plain name, a definition of done, and a rough duration. The whole sequence runs on any toolchain, and that vendor neutrality is why it holds up in front of a VP.
- Build a queryable inventory of shipped software. Which products and versions exist in the field, from which branches, produced by which repositories and pipelines. Done means a query answers in minutes, not a spreadsheet answers in weeks. Expect one to two quarters for the first business unit.
- Generate SBOMs per build with lineage to the commit. Use CycloneDX or SPDX, and treat SBOM automation in the pipeline as the goal rather than release-time documents. Done means every build emits one automatically. Expect about a quarter for the instrumented lines.
- Stand up exploitability triage. CVE volume across a mature embedded portfolio makes severity-based triage unworkable, so the deciding question becomes whether the vulnerable path is reachable and exploitable in that product. Done means the backlog ranks by exploitability, not CVSS alone. Expect a quarter of tuning to trust the ranking.
- Write an audit-and-disclosure runbook with named owners. Who declares awareness, who produces the customer evidence export, who signs, and rehearse it before an audit or a regulator makes you. Done means a timed dry run beat your tightest SLA. Expect it to take weeks rather than months.
- Put guardrails at the point of writing. Controls in the editors, pipelines, and AI coding tools engineers already use, so the next decade of product lines does not inherit this decade’s cleanup. Done means new code enters governed paths by default. Expect rollout to pace by team, not by tool.
The operating model deserves a mention, because nearly every multi-division manufacturer converges on the same shape. A corporate product security team owns standards, tooling, and the audit interface, while cyber champions inside each business unit own local adoption, and new acquisitions onboard through the same channel. The model works for the same reason quality programs work here, in that it matches how manufacturers already run themselves, and it deserves a deeper treatment than a pillar guide can give it.
Where Cycode Fits
Cycode is the Agentic Development Security Platform, and its fit for manufacturing runs straight through the 24-hour question. The platform’s SCA and Context Intelligence Graph maintain native lineage from commit to pipeline to artifact to runtime. That lineage is what turns the portfolio question, which shipped products across which versions contain this component, into something answerable.
Triage volume is where the fit shows next. The AI Exploitability Agent confirms whether a CVE is actually exploitable in the specific product context rather than merely present, and that confirmation is what makes CVE volume survivable for a mature embedded portfolio. The AI Fix and Remediation Agent then delivers PR-ready diffs, with 17x higher 90-day close rates, so fixes actually land. Together they turn triage from a staffing problem into a throughput number.
The forward-looking fit covers the code being written now. AI Guardrails apply controls in the editors and AI coding tools engineers already use, so AI-generated code enters governed paths before it reaches an embedded repository. For the discipline as a whole, Cycode was ranked first in Software Supply Chain Security in Gartner’s 2025 Critical Capabilities for Application Security Testing. That benchmark travels well in procurement reviews, where platform choices need outside validation.
None of that changes the argument of this guide. The program described above is executable with any toolchain, and the audit that tests it does not care whose logo is on the tooling. What a platform changes is the time from the Tuesday-morning email to a provable answer, and in manufacturing that interval is the whole game. Shorten it and everything else in the program gets easier all at once.
