What Is Product Security?

What Is Product Security?

Product security is the security of the thing you ship, not the network you ship it from. For connected devices, that distinction is now written into law in three jurisdictions.

The pages ranking for this question mostly describe SaaS lifecycle security. One of them defines product security as protecting your own organization's infrastructure, then recommends firewalls, email gateways, and backup software. Another, published in January 2026, carries a scope note conceding that the term is also used for physical devices, firmware, and embedded systems, and then declines to cover that meaning.

If you build connected devices, that is the meaning you came for, and it is the one nobody is writing about.

It is also the one with a date attached. Reporting obligations under Article 14 of the EU Cyber Resilience Act apply from September 11, 2026, to products already sitting in customers' hands.

What follows covers the definition, how product security differs from application security and from enterprise IT security, the four things a program has to produce, what regulators now require and when, and the place these programs most often break.

More than 40 percent of respondents to a 2021 Ponemon Institute report say that product security is a priority in their organizations.

In October 2021, the Ponemon Institute asked more than 600 IT security professionals about the product security strategies they had implemented within their organizations. Here's a summary of what they learned:

• 41 percent of respondents report that product security is an organizational priority
• 50 percent of organizations assess product security before a product ships to customers
• 59 percent of organizations report losing sales due to product security concerns

Clearly, product security matters to an increasing number of organizations, but not to as many as it should. When you approach your organization about product security, and they ask you to define it, how do you define product security? What makes product security different from other forms of IoT security?

Finally, why should organizations invest resources into product security? Read on for Finite State's perspective.

Defining Product Security

Product security encompasses the efforts that developers or manufacturers undertake when they build a secure product. It's important to emphasize the words "when they build" in that definition because product security, done right, forms an integral part of the creation of a product.

Product security is not something that only happens after a product is manufactured, or, worse, when an end-user opens a box that contains, for example, a doorbell camera, and wonders how to make sure that it's secure. The product security of that doorbell camera should be contemplated before it's ever shipped to a customer, and even before it rolls off an assembly line.

Product security has been around for a long time, but today, it's growing in importance and adoption. In the security ecosystem, product security runs parallel to two other well-established categories:

• IoT security
• AppSec

In IoT security, we try to protect devices on our networks with security programs that identify attacks when they happen and then we try to respond quickly, even though these devices are often unmanaged.

In AppSec, or application security, we look to static and dynamic application security testing, as well as software composition analysis. AppSec ensures that development teams are building their applications securely and not setting the stage for lots of fires to put out later because we have insecure network applications.

How Is Product Security Different Than Other Forms of IoT Security?

Beyond IoT security and AppSec, product security helps embedded device teams build secure products. Because embedded devices often combine hardware and software components, product security frequently looks to AppSec to improve software security. But, that's only part of the solution.

Product security means making sure the products that we ship are secure and abstract tools generally will not work on embedded systems. These tools have been designed to support web applications that run in different languages, on different systems, and according to different deployment cycles than those used in embedded devices.

When they build embedded devices, engineers and developers risk integrating vulnerabilities and threats from third-party components, which can include hardware, software, firmware, drivers, and operating systems. These opaque threats can come from any one of the components that would appear on a Software Bills of Materials, and AppSec tools just aren't designed to see into the composition of devices, identify potential vulnerabilities, and then determine their severity.

Product Security vs Application Security: Why the Tooling Differs

Scope is the easy half of that distinction. The mechanical half is what decides which tools you can actually use.

Application security assumes you hold the repository. It reads source, it reads dependency manifests, and both of those describe what your build system was told to fetch. That assumption holds for a web application your team wrote. It does not hold for a device.

Embedded C and C++ have no standard package manager. Components arrive as vendored trees, copied files, generated code, and supplier blobs dropped into a board support package by someone outside your company. A build system records what it was instructed to include. It cannot record what a chipset vendor compiled into an image before handing it over.

The concrete failure is easy to reproduce. When a component such as FFmpeg is statically compiled into a binary rather than declared as a dependency, it may not appear in a manifest-derived SBOM at all, absent a binary analysis step that detects embedded libraries by code signature. The scanner did not miss it. The scanner was never shown it.

Legacy is where the gap becomes obvious. A SKU that shipped in 2019 has a build environment nobody can reconstruct and a supplier who may no longer answer email, so there is no manifest to read and no source to scan. The image still exists, because it is running in the field, and reading it is the only route to an inventory.

Read that last column honestly. Binary analysis does not replace source analysis on code you wrote, and your manifests remain the right tool for the parts of the product you control. You need both. What you cannot do is run only the first column and call the result product security.

Product Security vs Enterprise IT Security: A Distinction the Search Results Get Wrong

A page currently ranking for this exact query defines product security as protecting an organization's infrastructure from cyberattacks and data loss. It then recommends firewalls, email security gateways, password length rules, network segmentation, and backup software.

Every one of those controls is real. Not one of them touches a product you sold.

Here is the test. If a control stops mattering the moment the product leaves your building, it was never product security. A firewall on your corporate network does nothing for a device on a hospital ward, in a substation, or bolted to a factory floor. Your backup strategy protects your data. It does not protect the customer running your firmware.

The confusion is expensive because the two disciplines answer to different people. Enterprise IT security answers to your own risk appetite, and you decide what residual risk is acceptable. Product security answers to somebody else's, and that somebody can deny you a market. The next section covers who and on what schedule.

One overlap is genuine, and pretending otherwise would be sloppy. Your build pipeline is both. A signing key stolen off your corporate network becomes a product problem the moment it signs firmware. The disciplines are distinct in what they protect, not hermetically sealed from one another.

If every metric in your product security program could be gathered without touching a shipped artifact, you are measuring the wrong program.

The Four Things a Product Security Program Has to Produce

Competitor pillar lists share a property worth noticing. Every item is something you can claim to be doing and nobody can check. "Establish ownership and governance" has no failure state. Neither does "shift left."

Four outputs do. Each one is an artifact somebody outside your team can ask for, and each one fails visibly.

1. An inventory of what shipped. Not what the build intended to ship. It covers first-party code, commercial components, open source, off-the-shelf software, and anything a supplier handed you as a binary. The failure state is finding a component in your own product that never appeared in your own list, which analysts who scan finished commercial software report as a routine result rather than an edge case.
2. A prioritization you can defend. The question is whether the vulnerable code is present, reachable, and triggerable in the artifact you shipped, not whether a version string matched a CVE. Counting findings is not measuring risk. The failure state is a backlog nobody can rank, which is how a team ends up patching the loud finding and shipping the exploitable one.
3. A staffed intake and reporting path. Coordinated disclosure with a named owner, not a policy PDF. The failure state is a researcher emailing working exploit code against a device already in service, and nobody knowing who files the 24-hour notification at 2 a.m. or who covers that person on a Saturday.
4. Evidence an assessor accepts. Technical documentation, per-component data, and traceability that survives someone else's review rather than your own. The failure state is documentation assembled by hand the week before an audit, which is also the version that cannot be reproduced next quarter.

Three of those four are things most teams believe they already have. The section after next is about the one they usually do not.

What Regulators Now Require, and When

Most coverage of the Cyber Resilience Act points at December 2027. The obligation that binds first applies from September 11, 2026, and it reaches products you shipped years ago.

The trap is in the legacy provisions. Article 69(2) exempts products placed on the market before December 2027 from full compliance unless they are substantially modified after that date. Article 69(3) overrides that carve-out specifically for Article 14. A device you shipped in 2020 and have not touched since still needs a working 24-hour reporting capability.

There is a limit on that, and it belongs here. Article 14 is not retroactive. Active exploitation you already knew about before September 11, 2026 does not become reportable on that date.

Two triggers run on two different clocks, which most summaries flatten. An actively exploited vulnerability and a severe incident both require an early warning within 24 hours and a fuller notification within 72. The final report is due within 14 days after a corrective measure becomes available for the vulnerability track, and within one month of the 72-hour notification for the incident track. The commonly cited "24/72/14" cadence drops the second one.

The SBOM guidance moved too, and it moved toward the artifact. The 2026 minimum elements make component hash a required field where the 2021 NTIA document listed it as recommended. A hash is a property of a thing you have. You cannot compute one for a component you never extracted.

Notice what none of these instruments do. Not one of them tells you which tool to use or which format to emit. They state an outcome and leave the method to you, which means the burden of proof sits with whoever has to defend the artifact.

Where Product Security Programs Break: The Inventory Nobody Verified

A wrong inventory does not fail loudly. It answers.

Asked how often an independent look at finished software disagrees with the component list that shipped alongside it, the CEO of one binary analysis firm said it happens more often than most organizations expect, and that across thousands of analyzed commercial packages they keep finding components that appear nowhere in the original SBOM. The sources are unglamorous: inherited code, third-party SDKs, a directory somebody copied in during a 2019 crunch.

The consequence is worse than a missed alert. When a Log4Shell-class disclosure lands and the affected component is absent from your inventory, your team searches, finds nothing, and reports up that the product is unaffected. That answer is clean, fast, and wrong. Nobody sees a gap, because a gap is exactly what the tooling could not show.

Supplier code does not move the duty. The manufacturer placing a product on the market owns the whole product, including firmware from an ODM or a chipset vendor. An ODM that refuses to supply an SBOM creates a liability for you rather than for itself. Fix that contractually, then verify it technically anyway, because a supplier's list is a claim about their build and not evidence about your image.

What a board usually hears is which tool produced the SBOM. What it should ask is what independently confirms it. Three words, and most programs cannot answer them: how do you know?

Whether your inventory is a claim or evidence comes down to a single question. Has anything other than your build system ever looked at the product?

How to Improve Your Product Security

Through the Finite State product security platform, we can help device developers and manufacturers instill confidence in the security of their products. We purposely built the Finite State Platform to assess product security in connected devices and embedded systems and deliver actionable insights, critical vulnerability data, and remediation guidance you can use.

Gain control of product security for your connected devices and supply chains. Mitigate product risk. Protect your connected attack surface.

There are more than 20 billion connected devices in use today. If you're ready to take the next step toward product security, talk to the Finite State team today. We'll show you how scalable and automated a leading-edge product security program can be.

Key Takeaways and Where to Start

• Product security is what you ship, not what you run. If a control stops mattering once the product leaves the building, it was enterprise IT security wearing a different label.
• AppSec and product security are not interchangeable. Application security tools read repositories. A shipped device is not a repository.
• Four outputs, not four principles. An inventory of what shipped, a defensible prioritization, a staffed reporting path, and evidence an assessor accepts.
• September 11, 2026 is the near date, not December 2027. CRA Article 14 reporting reaches products already in the field.
• Component hash is now a required SBOM field. You cannot hash a component you did not extract.
• The inventory is where programs break. A wrong one produces confident answers rather than visible gaps.

One first move, and it costs an afternoon. Pull the SBOM you would file today, pick five third-party components, and ask what confirms each one is present in the shipped image at that version. Blank answers are your gap.

Three questions worth putting to your team this month:

1. Who files the 24-hour notification, by name, and who covers that person at 2 a.m. on a Saturday?
2. Which SKUs still in the field would we have to report on, and can we enumerate their components today?
3. For every supplier-provided binary in our images, what confirms the supplier's component list?