Most of the security of a software product is decided before an engineer writes a line of code, in the roadmap, the defaults and the acceptance criteria that a product manager owns. Secure by design guidance from CISA, the UK Software Security Code of Practice and the EU Cyber Resilience Act all place the burden on the software maker, and inside the maker that burden lands on whoever decides what ships and in what state. This guide is for product managers, product owners and heads of product who build software sold to or used by others. It covers how to run a threat modelling session as a PM, which defaults to set, how to write security requirements and acceptance criteria that engineers can test, and how to prioritise security work against features. If you are looking at security product management as a career, see the Security Product Manager Career Guide instead; this page is about the security duties of every PM.
Key takeaways
- Security is a product decision. Defaults, pricing of security features, log retention and support periods are product choices with security outcomes, and regulators now treat them that way.
- Ask the four questions early. "What are we working on, what can go wrong, what are we going to do about it, did we do a good enough job" fits naturally into discovery and refinement.
- Secure out of the box, at no extra cost. MFA, logging and access control should work without configuration and should not sit behind a premium tier.
- Write requirements engineers can test. Tie each security story to an acceptance criterion and, where possible, to an OWASP ASVS 5.0 requirement at the right level.
- Budget for the whole life. Vulnerability handling, updates and end-of-support notice are part of the product, so plan capacity for them like any other feature.
Why product managers own security outcomes
CISA defines secure by default products as ones that are secure to use out of the box, with little or no configuration and at no additional cost, giving MFA, logging of potential intrusions and control of access to sensitive information as examples. Those are not engineering decisions alone: whether MFA is on by default, whether logs are included in the base plan and how long they are kept are packaging and pricing calls.
The UK Software Security Code of Practice, first published on 7 May 2025, makes the same point from the governance side. It is aimed at senior leaders of software vendors, who should appoint a Senior Responsible Owner, and its 14 provisions include applying secure by design and secure by default principles (1.4), telling customers the level of support provided (4.1) and giving at least one year's notice before support ends (4.2). In the EU, the Cyber Resilience Act entered into force on 10 December 2024; reporting of actively exploited vulnerabilities starts on 11 September 2026 and the main obligations apply from 11 December 2027. See the EU Cyber Resilience Act Guide and the Software Liability and Secure by Design Policy Guide for the legal detail.
| Product decision | Security outcome | Where it is expected |
|---|---|---|
| Is MFA on by default, and is phishing-resistant MFA available? | Fewer customer account takeovers | CISA Secure by Design Pledge goal 1; Secure by Demand questions |
| Are default passwords shipped or forced to change at setup? | Removes a common mass-exploitation route | Pledge goal 2 |
| Is SSO included in the standard price? | Customers can centralise identity and offboarding | Secure by Demand guide |
| Which logs ship in the base product, and for how long? | Customers can investigate intrusions | Pledge goal 7; Secure by Demand recommends at least six months for SaaS, at no extra charge |
| How are updates delivered? | Patches actually get applied | Pledge goal 4; UK Code 3.5 |
| What is the support period and end-of-life notice? | Customers can plan replacement | UK Code 4.1 and 4.2; CRA |
Threat modelling as a product manager
The OWASP Threat Modeling Cheat Sheet frames the work around four questions and recommends doing it early, during design, as a standard step in the lifecycle rather than an add-on, with the model kept up to date as the system changes. A PM does not need to be a security specialist to lead the first two questions; the PM already knows the users, the data and the business flows better than anyone. See the Threat Modelling Guide for methods and the Threat Model Template for a ready format.
- What are we working on? Bring a simple flow diagram of the feature: who uses it, which data it touches, which other systems and third parties it calls, and which machine credentials (API keys, OAuth clients, service accounts) it needs.
- What can go wrong? Walk the flow with STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) and add abuse cases from the business side: refund abuse, scraping, inviting attackers into a tenant, bypassing a paid limit. The Abuse Case Library Template helps.
- What are we going to do about it? Turn each accepted threat into a backlog item with an owner, or record an explicit risk acceptance signed by the product owner.
- Did we do a good enough job? Check at release that the mitigations exist and the tests pass, and revisit the model when the feature changes.
When to run one: NHI Mgmt Group suggests a short session (30 to 60 minutes) for any epic that adds a new data type, a new external integration, a new authentication or permission path, a new public API, or an AI feature that can take actions. Small UI changes do not need one.
Secure defaults to decide up front
The CISA Secure by Design Pledge lists seven goals, and the CISA and FBI Secure by Demand Guide turns them into questions customers ask during procurement. Treat the list below as a product specification checklist, because your buyers increasingly will.
- Authentication: standards-based SSO at no extra cost; MFA enabled by default; phishing-resistant options such as passkeys, at least for administrators. See the Phishing-Resistant MFA Guide.
- No default passwords: unique setup credentials or a forced change at first use, especially for internet-facing products. The Default Credential Breaches Lessons Guide shows why.
- Least privilege roles: ship sensible roles (viewer, editor, administrator) so customers do not give everyone admin; make tenant-wide actions require an administrator.
- Machine access: scoped, expiring API keys or OAuth clients per integration, with the key shown once and a rotation path in the UI. See the API Key Management Guide.
- Evidence of intrusions: configuration, identity and data access logs in the base product, exportable to the customer's SIEM.
- Updates: automatic updates where possible; for SaaS, the vendor patches without customer action.
- Safe sharing: private by default for links, buckets, workspaces and new projects.
Trade-off to manage: every secure default adds a little friction at onboarding. Rather than turning the default off, invest design effort in the flow (passkeys, magic sign-in for low-risk actions, a clear first-run security wizard) and measure activation before and after.
Writing security requirements and acceptance criteria
Vague stories such as "make it secure" never get tested. OWASP ASVS 5.0 gives a catalogue of testable requirements in 17 chapters, from V6 Authentication and V8 Authorization to V16 Security Logging and Error Handling, at three levels. A PM can pick the level for the product (NHI Mgmt Group suggests Level 1 as a minimum, Level 2 for most products handling personal or business data, and Level 3 for the most sensitive) and reference the relevant chapters in epics. The OWASP ASVS Guide and the Application Security Requirements from ASVS template help with selection.
| Story area | Example acceptance criterion | ASVS 5.0 chapter |
|---|---|---|
| Sign-in | Admin users cannot complete setup without registering MFA; passkeys are offered | V6 Authentication |
| Sessions | Sessions end on sign-out and after a defined idle period; password change ends other sessions | V7 Session Management |
| Permissions | A user in tenant A receives a 403 or 404 for any object ID belonging to tenant B | V8 Authorization |
| API tokens | Tokens have an expiry, a scope list and can be revoked by the customer from the UI | V9 Self-contained Tokens; V10 OAuth and OIDC |
| Input | All database queries in the feature use parameterised queries | V1 Encoding and Sanitization |
| File upload | Only listed file types and sizes are accepted and files are not served from the app origin | V5 File Handling |
| Business rules | Rate and quantity limits are enforced server-side | V2 Validation and Business Logic |
| Audit | Role changes, key creation and exports are logged with actor, time and source | V16 Security Logging and Error Handling |
Definition of done: add a security line to the team's definition of done (threat model updated if needed, security acceptance criteria passed, no new high findings from scanning, new secrets stored in the approved secrets manager). See the Business Logic Vulnerabilities Guide for flaws that scanners rarely find and that PMs are best placed to spot.
Prioritising security work in the roadmap
Security items compete with features for the same capacity. A few rules make the trade-off explicit rather than silent.
| Type of work | How to prioritise (NHI Mgmt Group suggestion) |
|---|---|
| Actively exploited or critical vulnerability | Interrupts the sprint; tracked to the agreed fix time |
| Missing secure default from the list above | Roadmap item with a target quarter, visible to sales and support |
| Eliminating a vulnerability class (for example moving to a safe query layer or memory-safe component) | Funded as a multi-quarter investment, matching Pledge goal 3 |
| High findings from testing | A fixed share of each sprint, agreed with engineering |
| Customer security questionnaire gaps | Grouped and weighed by revenue at risk, not handled one deal at a time |
Small and large organisations: a start-up with one product team can keep threat models in the epic description and a single security backlog label. A larger vendor should set a product security baseline across all products, a named security contact per product line, and a security champion in each team. See the Security Champions Programme Guide.
Lifecycle duties beyond launch
- Vulnerability disclosure: publish a policy that authorises good-faith testing and gives a reporting channel (Pledge goal 5, UK Code 3.2). See the Vulnerability Disclosure Policy Template.
- CVE transparency: issue CVEs for critical or high-impact issues that need customer action, with accurate CWE and CPE fields (Pledge goal 6).
- Components: know what is in the product and assess third-party components (UK Code 1.2); provide an SBOM when customers ask. See the SBOM Guide.
- Support periods: state the support period at sale and give at least one year's notice before support ends (UK Code 4.1, 4.2).
- Incidents: agree in advance what the product team publishes about notable incidents (UK Code 4.3) and who approves it.
Where identity fits
Many products now create non-human identities on behalf of customers: integration tokens, webhooks with signing secrets, service accounts and AI agents that act in the product. Each is a credential that can leak. The product questions are simple: can the customer see every token and who created it, can they set an expiry, can they revoke it in one click, and do logs show which token did what? Building these into the first release is far cheaper than retrofitting. See the Secrets Management Guide for the engineering side.
Detection and measurement
- Secure default adoption: percentage of active tenants with MFA enforced for administrators, and with SSO configured.
- Threat model coverage: percentage of qualifying epics shipped with a threat model reviewed in the last release cycle.
- Security acceptance pass rate: share of security acceptance criteria passing at first test.
- Time to fix: median days from report to fix for critical and high vulnerabilities, against the agreed target.
- Repeat classes: count of new findings in vulnerability classes you set out to eliminate; it should trend to zero.
- Log availability: share of customers who can export identity and configuration logs without a paid add-on.
Framework mapping
| PM activity | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | Other |
|---|---|---|---|
| Security in the development lifecycle | SA-3, SA-15 | PR.PS-06 | NIST SSDF (SP 800-218); UK Code 1.1 |
| Threat modelling and design principles | SA-8, PL-8, RA-3 | PR.PS-06 | UK Code 1.4 |
| Security testing against requirements | SA-11 | ID.RA-01 | OWASP ASVS 5.0; UK Code 1.3 |
| Accounts, MFA and token management in the product | AC-2, IA-5 | PR.PS-06 | Pledge goals 1 and 2 |
| Component and supplier risk | SR-3 | GV.SC-05 | UK Code 1.2 |
For the full practice set see the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide.
Common failure patterns
- Security features sold as add-ons: SSO or audit logs only in the enterprise tier, so most customers run without them.
- Defaults chosen for the demo: open sharing and no MFA because they make onboarding look smooth, then never revisited.
- Threat modelling once: a model done at the start of the product and never updated as integrations and AI features are added.
- Untestable stories: "secure the API" with no acceptance criterion, so nobody can say whether it was done.
- Keys without a lifecycle: integration keys that never expire and cannot be listed or revoked by the customer.
- No end-of-life plan: old versions left running without notice or migration path.
Practitioner checklist
- List the product's security defaults and compare them with the seven CISA Pledge goals.
- Add a threat modelling trigger list to your refinement process and run the four questions for qualifying epics.
- Pick an OWASP ASVS 5.0 level for the product and reference chapters in security stories.
- Add a security line to the definition of done.
- Make MFA, SSO and core audit logs available in the base product.
- Give customers a token inventory with expiry and one-click revocation.
- Publish a vulnerability disclosure policy and a support period statement.
- Track the six metrics above in the product review alongside adoption and revenue.
Standards and references
- CISA: Secure by Design
- CISA: Secure by Design Pledge
- CISA and FBI: Secure by Demand Guide
- DSIT and NCSC: Software Security Code of Practice
- European Commission: Cyber Resilience Act
- NIST: SP 800-218 Secure Software Development Framework
- OWASP: Threat Modeling Cheat Sheet
- OWASP: Application Security Verification Standard
Related NHI Mgmt Group resources: Application Security Guide · Threat Modelling Guide · Developer Security Training Programme Guide · Privacy by Design Guide for Engineering Teams