Many organisations call their software security team "AppSec" or "ProdSec" without deciding what the team is actually accountable for, and the gap only shows when a customer reports a vulnerability in a product version nobody owns. Application security protects the code and services an organisation builds and runs; product security is accountable for everything a customer receives and keeps running, including firmware, installers, update channels, third-party components and old versions still in the field. The difference now has legal weight: the EU Cyber Resilience Act places vulnerability handling, support period and reporting duties on manufacturers, not on development pipelines. This guide compares the two mandates in depth: scope, threat model, reporting lines, operating models, regulatory obligations, metrics and worked scenarios, with a decision checklist for leaders designing or splitting the function. It is for CISOs, engineering leaders and heads of AppSec. Individual career paths are covered in the Product Security Engineer Career Guide and the Application Security Engineer Career Guide; this page is about the team.
Key takeaways
- The unit of risk differs. AppSec measures risk in the systems the organisation operates; product security measures it across every customer running what was shipped, including versions the organisation can no longer change.
- Product security owns the after-life of a release. Support periods, security updates, advisories and regulatory reports continue for years after a version ships; the CRA sets a support period of at least five years unless the product's expected use time is shorter.
- AppSec is usually a subset, not a peer. In a company that ships products, secure development is one stage of the product security mandate, alongside PSIRT, supply chain, signing and update infrastructure, and hardware where relevant.
- Reporting lines decide outcomes. FIRST says a PSIRT needs autonomy and an executive sponsor who confirms its authority; a product security function buried three levels down in one engineering group cannot hold a release or speak to a regulator within 24 hours.
- Metrics should follow the mandate. AppSec metrics describe pipeline hygiene; product security metrics describe customer exposure: time to fixed release, advisory quality, support period coverage and on-time regulatory reports.
The short answer
If your organisation only builds software it runs itself (internal systems, a single SaaS platform it operates), you need application security: a team that embeds secure design, testing and remediation into the development life cycle. If you ship anything a customer installs, flashes, deploys or depends on, including a SaaS platform with customer-facing APIs, SDKs, agents or connectors, you need product security: a mandate that runs from requirements to end of support and includes vulnerability intake, coordinated disclosure, security updates and regulatory reporting. Most software companies need both, with AppSec as the engineering arm of a wider product security function. The reverse arrangement, where a product security lead reports into an AppSec manager focused on scanner coverage, tends to leave PSIRT, signing keys and support period decisions without an owner.
Side-by-side comparison
| Dimension | Application security | Product security |
|---|---|---|
| What it protects | Code, services and APIs the organisation builds and operates | Every product and service a customer receives, and the customer's use of it |
| Life cycle span | Design to deployment, plus production fixes | Requirements to end of support, including versions in the field |
| Typical scope | SAST, SCA, DAST, secrets scanning, threat modelling, security champions | All of AppSec plus PSIRT, advisories, SBOM and VEX, signing and update channels, hardware and firmware, secure defaults |
| Who reports problems | Internal tools, pen testers, bug bounty for owned assets | Customers, researchers, CERTs, upstream maintainers, regulators |
| Can you patch it yourself? | Usually yes, by redeploying | Often no: the customer must apply the update, sometimes years later |
| Main external obligations | Customer contracts, sector rules for the operator (for example PCI DSS Requirement 6) | Manufacturer duties: CRA Article 13 and 14, Annex I, IEC 62443-4-1 for industrial products, sector product rules |
| Typical reporting line | CISO or VP Engineering | CTO, Chief Product Officer or a dedicated product security officer, with a dotted line to the CISO |
| Core artefacts | Pipeline policy, findings backlog, threat models | Security requirements per product, SBOMs, advisories, support period statements, disclosure policy, regulatory reports |
Threat model: what each team is defending against
Application security
The AppSec threat model is the organisation's own attack surface: injection and access control flaws in services it runs, vulnerable open source in its deployments, leaked secrets in repositories, and weaknesses in CI/CD that let an attacker push code to production. The defender controls the runtime, so compensating controls (WAF rules, feature flags, rollbacks) are available within hours. The Application Security Guide covers this programme in depth.
Product security
The product security threat model adds three things AppSec rarely holds:
- Attacks on customers through the product: a vulnerability in a released firewall, agent or SDK is exploited across thousands of customer environments the vendor cannot see or patch. Exposure is measured in installed base, not in hosts.
- Attacks on the distribution chain: a stolen release signing key or a compromised update server lets an attacker ship code that every customer will trust. Key custody and update integrity belong to product security; see the Code Signing Security Guide and the IoT Secure Firmware Update Guide (SUIT, signed OTA).
- Time: a product sold today may still run in a factory or hospital in ten years. Unsupported components (NIST SP 800-53 SA-22) become the product team's problem long after the developers who chose them have moved on.
Architecture of each function in words
A typical AppSec team
A central team of security engineers owns tooling (scanners in the pipeline, a findings platform such as an ASPM layer), secure design reviews and threat modelling for high-risk changes, and developer enablement. A security champions network extends reach into squads. Findings flow into engineering backlogs with severity-based SLAs. The team's maturity is often measured against OWASP SAMM, whose five business functions are Governance, Design, Implementation, Verification and Operations.
A typical product security function
Product security wraps AppSec in a wider structure with four additional parts:
- Product security requirements and secure defaults: a baseline for every product line (authentication, logging, hardening, update behaviour), mapped to regulation such as CRA Annex I Part I and, for industrial products, IEC 62443-4-2 component requirements. See the IEC 62443-4-1 and 4-2 Secure Product Development Guide.
- PSIRT: intake, triage, remediation coordination and disclosure. The FIRST PSIRT Services Framework 1.1 defines six service areas: Stakeholder Ecosystem Management, Vulnerability Discovery, Vulnerability Triage and Analysis, Remediation, Vulnerability Disclosure, and Training and Education. See the PSIRT Guide.
- Supply chain and transparency: component inventory, SBOM generation, VEX statements and upstream coordination with open source maintainers. See the SBOM Guide and the VEX Guide.
- Release integrity and support: signing infrastructure, update delivery, support period decisions per product and end-of-life communication.
FIRST is explicit that a PSIRT is not independent of product development: it is part of the organisation's secure engineering initiative and secure development life cycle. That is the clearest argument for placing AppSec and PSIRT under one product security leader rather than in separate silos.
Operating models and reporting lines
FIRST describes three PSIRT operating models, and the same choices apply to the wider product security function.
| Model | How it works | Fits | Main risk |
|---|---|---|---|
| Distributed | A small core team sets policy and coordinates; product security representatives sit in each product team | Large, diverse portfolios (many product lines, acquisitions) | The people who triage and fix do not report to the security function, so priorities drift |
| Centralised | A larger central team, drawn from several departments, reports to one or more senior executives | Small or homogeneous portfolios | Scales poorly as the portfolio grows or diversifies |
| Hybrid | Central ownership of PSIRT, disclosure, signing and policy; embedded engineers or champions for design and testing | Most mid-size and large software and device makers | Unclear boundaries unless a RACI is written down |
Where to report: AppSec commonly reports to the CISO because its work overlaps with enterprise vulnerability management and the CISO's control framework. Product security needs authority over release decisions and product roadmaps, so it often reports to the CTO or Chief Product Officer, with a dotted line to the CISO for shared tooling and incident handling. Whatever the line, the executive sponsor must be able to approve a delayed release, a free security update for an out-of-warranty product, or a public advisory, without escalating through three layers.
Splitting with the enterprise CSIRT: FIRST distinguishes the PSIRT, which handles vulnerabilities in what the organisation sells, from the enterprise CSIRT, which protects the organisation's own systems and networks, and expects them to collaborate. The handoff that matters most is the incident that is both: a compromised build server is an enterprise incident and a product integrity incident at the same time. See the Secure SDLC vs DevSecOps comparison for how pipeline ownership interacts with these lines.
Regulation: why the line between the two now matters
The Cyber Resilience Act, Regulation (EU) 2024/2847, applies to manufacturers of products with digital elements placed on the EU market. Its duties map almost entirely onto the product security mandate, not onto a pipeline-focused AppSec team. Status as checked on 14 November 2026: the regulation entered into force on 10 December 2024; Article 14 reporting obligations apply from 11 September 2026; Chapter IV (notified bodies) from 11 June 2026; the rest from 11 December 2027 (Article 71(2)).
| CRA obligation | Source | Natural owner |
|---|---|---|
| Essential cybersecurity requirements in design and development | Annex I Part I | AppSec, under product security requirements |
| Machine-readable SBOM covering at least top-level dependencies | Annex I Part II(1) | Product security (supply chain) |
| Fix vulnerabilities without delay; security updates separate from feature updates where technically feasible | Annex I Part II(2) | Product security with engineering |
| Regular security tests and reviews | Annex I Part II(3) | AppSec |
| Public disclosure of fixed vulnerabilities; coordinated vulnerability disclosure policy; reporting contact | Annex I Part II(4) to (6) | PSIRT |
| Secure update distribution; fixes free of charge with advisory messages | Annex I Part II(7) and (8) | Product security (release integrity) |
| Support period of at least five years, or the expected use time if shorter | Article 13(8) | Product management with product security |
| Actively exploited vulnerabilities: early warning within 24 hours, notification within 72 hours, final report no later than 14 days after a corrective or mitigating measure is available | Article 14(2) | PSIRT |
Breaches of the essential requirements and of Articles 13 and 14 can attract administrative fines of up to EUR 15 000 000 or 2.5% of worldwide annual turnover, whichever is higher (Article 64(2)). The reporting and support period duties sit with the manufacturer as a legal entity, so a team whose mandate stops at "the pipeline" cannot carry them. The EU Cyber Resilience Act Vulnerability and Incident Reporting Guide covers the reporting mechanics. Outside the EU, voluntary commitments point the same way: CISA's Secure by Design pledge asks enterprise software manufacturers for progress on seven goals, including MFA, default passwords, reducing entire classes of vulnerability, security patches, a vulnerability disclosure policy, CVE quality and evidence of intrusions. Several of those (patches, disclosure, CVEs) are product security work.
Failure modes of each model
| Arrangement | What goes wrong | Control |
|---|---|---|
| AppSec only, in a company that ships products | Researcher reports land in a support queue; no one owns advisories, CVE assignment or support period decisions | Stand up a PSIRT with an ISO/IEC 29147 aligned disclosure policy and named owner |
| Product security as a renamed AppSec team | Scanner coverage grows but signing keys, update servers and old firmware lines have no owner | Write the mandate to cover release integrity and support, and fund it |
| PSIRT separate from AppSec with no feedback loop | The same vulnerability class recurs in each release because root causes never reach design reviews | Route PSIRT root cause data into threat modelling and secure coding training (FIRST service 6.2) |
| Distributed model without central authority | Each product line sets its own fix timelines; customers get inconsistent advisories | Central policy on severity, fix targets and advisory format, enforced by the executive sponsor |
| Product security reporting only to the CISO in a large manufacturer | Little say over roadmaps and release dates; secure defaults lose to feature deadlines | Dual reporting into the CTO or CPO, with release-blocking authority written into policy |
Where identity fits
Both teams handle machine credentials, but in different places. AppSec owns the secrets developers and pipelines use: repository tokens, cloud deployment roles and scanner credentials, covered in the Application Security Guide. Product security owns the identities that ship with or serve the product: release signing keys, device identity certificates provisioned at manufacture, update service credentials, default accounts (a CISA pledge goal) and the API keys or OAuth clients that customers' integrations use. A leaked signing key or a hardcoded device credential becomes a customer-wide incident, so these keys need hardware-backed custody, short-lived build identities and documented revocation plans. See the Code Signing Policy Template.
Metrics for each mandate
| Application security metric | Product security metric |
|---|---|
| Percentage of repositories with SAST, SCA and secrets scanning in the pipeline | Percentage of supported product versions with a current SBOM and stated support period |
| Median time to remediate critical findings in owned services | Median time from validated report to fixed release available to customers |
| Reopen rate of fixed findings | Recurrence of the same CWE across releases (root cause effectiveness) |
| Threat models completed for high-risk changes | Products meeting the internal secure-by-default baseline at release |
| Champion coverage per squad | On-time CRA early warnings and notifications (24 and 72 hours) |
| Findings backlog age | Advisories published with CVE, affected versions, fixed versions and VEX status |
The AppSec Programme Metrics Guide covers the left-hand column in detail. Report the right-hand column to the executive sponsor quarterly, because it describes exposure the board and regulators care about.
Worked scenarios
Scenario 1: a single-tenant SaaS company
A 300-person company runs one SaaS platform and offers no installable software. A central AppSec team of three, reporting to the CISO, owns the pipeline, threat modelling and a bug bounty. The gap appears when the company launches a public SDK and a customer-hosted connector: those are now products in the hands of customers, the company cannot redeploy them, and researcher reports about them need advisories. Decision: keep AppSec where it is, add a PSIRT responsibility (one named lead, a disclosure policy following ISO/IEC 29147, and an advisory format), and define support periods for SDK and connector versions. The Bug Bounty and Vulnerability Disclosure Guide covers the intake side.
Scenario 2: a connected device manufacturer selling in the EU
A manufacturer ships firmware-based devices with a mobile app and cloud back end. It had a two-person AppSec team scanning the cloud code. Under the CRA it must produce SBOMs, operate coordinated disclosure, deliver free security updates for at least five years, and report actively exploited vulnerabilities within 24 hours. Decision: create a product security function under the CTO with a hybrid model: a central PSIRT and supply chain lead, a firmware security engineer, ownership of the signing HSM and update service, and the existing AppSec engineers moving under the same leader. Support period becomes a product management decision recorded per SKU, reviewed by product security. The EU Cyber Resilience Act Readiness Checklist for Manufacturers gives the full gap list.
Scenario 3: a large enterprise software vendor after an acquisition
A vendor with 40 product lines acquires three companies, each with its own security habits. A purely centralised team cannot cover the portfolio. Decision: distributed model with a strong core. The core owns policy, severity scoring (see the CVSS v4 Guide), advisory publishing, CVE numbering and regulatory reports; each product line names a product security representative whose objectives include fix targets set by the core. Integration milestones for acquisitions include SBOM coverage and adoption of the shared disclosure process within a fixed window.
How to implement or reshape the function
- Inventory what you ship: list every product, SDK, agent, image, firmware line and customer-facing API, with supported versions. Anything a customer runs or integrates is in product security scope.
- Write the mandate: one page stating what each team owns, using the CRA obligations table above as a checklist, and who can block a release.
- Pick the operating model: centralised for a small homogeneous portfolio, distributed with a strong core for many lines, hybrid for most. Write a RACI for intake, triage, fix, advisory, regulatory report and support period.
- Set the reporting line: name an executive sponsor with authority over release dates; add a dotted line to the CISO for shared tooling and incident escalation.
- Pilot on one product line: run intake to advisory end to end, including a tabletop of a 24-hour CRA early warning, before rolling out across the portfolio.
- Connect the feedback loop: feed PSIRT root causes into threat models, secure coding training and secure defaults each quarter.
- Review and roll back if needed: if a distributed model leaves fix targets unmet for two quarters, pull triage back to the core until representatives are trained.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-02 | Roles, responsibilities and authorities: the written mandate and RACI |
| NIST CSF 2.0 | PR.PS-06 | Secure software development practices integrated and monitored: AppSec core |
| NIST CSF 2.0 | ID.RA-08 | Processes for receiving, analysing and responding to vulnerability disclosures: PSIRT |
| NIST CSF 2.0 | GV.SC-05 | Supply chain requirements in contracts: upstream components and suppliers |
| NIST SP 800-53 Rev 5 | SA-8, SA-11, SA-15 | Engineering principles, developer testing, development process: AppSec |
| NIST SP 800-53 Rev 5 | SR-4, SA-22 | Provenance and unsupported components: product security across the life cycle |
| NIST SP 800-218 (SSDF) | PO, PS, PW, RV practice groups | Protect the Software and Respond to Vulnerabilities extend beyond the pipeline into product security |
| ISO/IEC 27001:2022 Annex A | A.8.25, A.8.8 | Secure development life cycle; management of technical vulnerabilities |
| CIS Controls v8.1 | Control 16 | Application Software Security, including a process to accept and address vulnerability reports |
Decision checklist
- Do customers install, flash, deploy or integrate anything you build? If yes, you need a product security mandate, not just AppSec.
- Do you sell products with digital elements in the EU? If yes, map CRA Article 13, Article 14 and Annex I duties to named owners.
- Who can delay a release or fund a free security update for an old product? That person should sponsor product security.
- Is there one front door for vulnerability reports, with a published policy and a response target?
- Does anyone own the release signing keys, the update service and their revocation plans?
- Are support periods recorded per product and visible to customers?
- Do PSIRT root causes change design reviews and training?
Practitioner checklist
- Publish a one-page mandate for AppSec and product security, with a RACI covering intake to end of support.
- Name an executive sponsor for product security with release-blocking authority.
- Adopt a disclosure policy aligned with ISO/IEC 29147 and a handling process aligned with ISO/IEC 30111.
- Generate a machine-readable SBOM for every supported version and publish VEX where it helps customers.
- Put signing keys in hardware-backed custody with a tested revocation and re-signing plan.
- Rehearse a 24-hour CRA early warning and a 72-hour notification at least once a year.
- Report customer-exposure metrics (time to fixed release, advisory quality, support coverage) quarterly.
- Review the operating model after every acquisition or new product line.
Standards and references
- EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
- FIRST: PSIRT Services Framework 1.1
- NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
- ISO: ISO/IEC 29147:2018 Vulnerability disclosure
- OWASP: Software Assurance Maturity Model (SAMM) v2
- CISA: Secure by Design
- CISA: Secure by Design Pledge
Related NHI Mgmt Group resources: PSIRT Guide, EU Cyber Resilience Act Guide, Secure Software Development Lifecycle (SSDLC) Guide, Security Champions vs Centralised AppSec, Software Supply Chain Security Guide.