Minimum Viable Secure Product

Other versions:

Minimum Viable Secure Product (MVSP) is a list of essential application security controls that should be implemented in enterprise-ready products and services.

The controls are designed to be simple to implement and provide a good foundation for building secure and resilient systems and services.

We recommend that all companies building enterprise software and services, or otherwise handling sensitive information, implement the MVSP controls and, where possible, go well beyond them in their application security programs.

1 Business controls
Control	Description
1.1 External vulnerability reports ^FAQ	Publish a vulnerability disclosure policy that outlines the testing scope, provides a legal safe harbor, and gives contact details for security reports Example: Publish a policy generated with disclose.io and refer to it using security.txt (RFC 9116). Develop and document procedures for triaging and remediating reported vulnerabilities Respond to reports within a reasonable time frame Patch vulnerabilities consistent with Control 3.4
1.2 Customer testing ^FAQ	On request, enable your customers or their delegates to test the security of your application Test on a production or a non-production environment that closely resembles the production environment in functionality Ensure non-production environments do not contain production data Reasonable restrictions on testing can be defined
1.3 Self-assessment ^FAQ	Perform and make available security self-assessments for each qualifying product/service, using the latest MVSP release, at least annually
1.4 External testing ^FAQ	Contract a security vendor to perform comprehensive penetration tests of your products, services, and dependent systems, at least annually
1.5 Training ^FAQ	Implement role-specific security training for your personnel that is relevant to their business function
1.6 Compliance ^FAQ	Comply with industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18 Comply with local laws and regulations in jurisdictions applicable to your company and your customers, such as GDPR, Binding Corporate Rules, and Standard Contractual Clauses Ensure data localization requirements are implemented in line with local regulations and contractual obligations
1.7 Incident handling ^FAQ	Notify relevant parties about any security breach that affects sensitive information no later than 72 hours upon discovery, and upon learning any additional details of the breach Consider reporting the breach to relevant national cybersecurity agencies in line with local guidance and regulations Include the following information in the notification: Nature of the breach Relevant contact information Consequences of the breach Measures taken, or needing to be taken, to remediate the issue
1.8 Data handling ^FAQ	Ensure media sanitization processes based on NIST SP 800-88 (or equivalent) are implemented for storage media holding unencrypted production data
2 Application design controls
Control	Description
2.1 Single Sign-On ^FAQ	Implement single sign-on using modern, maintained, and industry-standard protocols for all customers at no additional cost
2.2 HTTPS-only ^FAQ	Redirect traffic from HTTP protocol (port 80) to HTTPS (port 443) This does not apply to secure protocols designed to run on top of unencrypted connections, such as OCSP Scan and address issues using freely available modern TLS scanning tools Include the Strict-Transport-Security header with a long `max-age` value Set authentication cookies as Secure
2.3 Security Headers ^FAQ	Apply appropriate security headers to reduce the application attack surface and limit post exploitation: Set a minimally permissive Content Security Policy Limit the ability to iframe the application by enabling framing controls with X-Frame-Options or CSP frame-ancestors Disable caching for APIs and endpoints that return sensitive data
2.4 Password policy ^FAQ	If password authentication is used in addition to single sign-on: Do not limit the permitted characters that can be used Do not limit the length of the password to anything below 64 characters Do not use secret questions as a sole password reset requirement Require email verification of a password change request Require the current password in addition to the new password during password change Store passwords in a hashed and salted format using a memory-hard or CPU-hard one-way hash function Enforce appropriate account lockout and brute-force protection on account access Do not provide default passwords for users or administrators
2.5 Security libraries ^FAQ	Use modern, maintained, and industry-standard frameworks, template languages, or libraries that systemically address implementation weaknesses by escaping the outputs and sanitizing the inputs Example: ORM for database access, UI framework for rendering DOM
2.6 Dependency Patching ^FAQ	Ensure third-party dependencies are maintained and up-to-date, with security relevant updates having a severity score of "medium" or higher applied in line with your application patching schedule Upon becoming aware of a Known Exploited Vulnerability affecting a third-party dependency, the patch should be prioritized Where dependency patching or upgrades are not possible, equivalent mitigations should be implemented for all components of the application stack
2.7 Logging ^FAQ	Keep logs of: Authentication events (success and failure) Create, Read, Update, and Delete (CRUD) operations on application and system users and objects Security relevant configuration changes (including disabling logging) Application owner access to customer data (access transparency) Logs must include user ID, IP address, valid timestamp, type of action performed, and object of this action. Logs must be stored for at least 30 days at no additional charge, and should not contain sensitive data or payloads.
2.8 Encryption ^FAQ	Use modern, maintained, and industry-standard means of encryption to protect sensitive data in transit between systems, and at rest in online data storages and backups
3 Application implementation controls
Control	Description
3.1 List of data ^FAQ	Maintain a list of sensitive data types that the application is expected to process
3.2 Data flow diagram ^FAQ	Maintain an up-to-date diagram indicating how sensitive data reaches your systems and where it ends up being stored
3.3 Vulnerability prevention ^FAQ	Train your developers and implement development guidelines to prevent at least the following vulnerabilities: Authorization bypass — Example: Accessing other customers' data or admin features from a regular account Insecure session management — Examples: Guessable token; a token stored in an insecure location (e.g. cookie without Secure and HttpOnly flags set) Injections — Examples: (No)SQL injection, LLM / Prompt injection, XXE, OS command injection Cross-site scripting — Examples: Calling insecure JavaScript functions, performing insecure DOM manipulations, echoing back user input into HTML without escaping Cross-site request forgery — Example: Accepting requests with an Origin header from a different domain Handling untrusted data — Example: Reusing data supplied by users within sensitive application contexts
3.4 Time to fix vulnerabilities ^FAQ	Produce and deploy patches to address application vulnerabilities that materially impact security within 90 days of discovery For vulnerabilities with evidence of active exploitation, production and deployment of patches should be prioritized Publish a security bulletin that details the vulnerability and its root cause if the remedy requires action from customers
3.5 Build and release process ^FAQ	Must use a version control system and consistent build process that generates provenance describing how the artifact was built (SLSA Build Level 1) Sensitive application credentials and tokens should be stored separately from the application’s source code
4 Operational controls
Control	Description
4.1 Physical access ^FAQ	Validate the physical security of relevant facilities by ensuring the following controls are in place: Layered perimeter controls and interior barriers Managed access to keys Entry and exit logs Appropriate response plan for unauthorized access
4.2 Logical access ^FAQ	Limit sensitive data access exclusively to users with a legitimate need. The data owner must authorize such access Deactivate redundant accounts and expired access grants in a timely manner Perform regular reviews of access to validate need to know Ensure remote access to customer data or production systems requires the use of Multi-Factor Authentication
4.3 Sub-processors ^FAQ	Maintain a list of third-party companies with access to customer data, and make it available to clients and business partners upon request Assess third-party companies annually against the latest MVSP release
4.4 Backup and Disaster recovery ^FAQ	Securely backup all data to a different location than where the application is running Maintain and test disaster recovery plans in concert with your incident response planning, at least annually or after significant changes

1 Business controls

Control

Description

1.1 External vulnerability reports ^FAQ

Publish a vulnerability disclosure policy that outlines the testing scope, provides a legal safe harbor, and gives contact details for security reports

Example:
Publish a policy generated with disclose.io and refer to it using security.txt (RFC 9116).

Develop and document procedures for triaging and remediating reported vulnerabilities
Respond to reports within a reasonable time frame
Patch vulnerabilities consistent with Control 3.4

1.2 Customer testing ^FAQ

On request, enable your customers or their delegates to test the security of your application
Test on a production or a non-production environment that closely resembles the production environment in functionality
Ensure non-production environments do not contain production data
Reasonable restrictions on testing can be defined

1.3 Self-assessment ^FAQ

Perform and make available security self-assessments for each qualifying product/service, using the latest MVSP release, at least annually

1.4 External testing ^FAQ

Contract a security vendor to perform comprehensive penetration tests of your products, services, and dependent systems, at least annually

1.5 Training ^FAQ

Implement role-specific security training for your personnel that is relevant to their business function

1.6 Compliance ^FAQ

Comply with industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18
Comply with local laws and regulations in jurisdictions applicable to your company and your customers, such as GDPR, Binding Corporate Rules, and Standard Contractual Clauses
Ensure data localization requirements are implemented in line with local regulations and contractual obligations

1.7 Incident handling ^FAQ

Notify relevant parties about any security breach that affects sensitive information no later than 72 hours upon discovery, and upon learning any additional details of the breach
Consider reporting the breach to relevant national cybersecurity agencies in line with local guidance and regulations

Include the following information in the notification:

Nature of the breach
Relevant contact information
Consequences of the breach
Measures taken, or needing to be taken, to remediate the issue

1.8 Data handling ^FAQ

Ensure media sanitization processes based on NIST SP 800-88 (or equivalent) are implemented for storage media holding unencrypted production data

2 Application design controls

Control

Description

2.1 Single Sign-On ^FAQ

Implement single sign-on using modern, maintained, and industry-standard protocols for all customers at no additional cost

2.2 HTTPS-only ^FAQ

Redirect traffic from HTTP protocol (port 80) to HTTPS (port 443)

This does not apply to secure protocols designed to run on top of unencrypted connections, such as OCSP

Scan and address issues using freely available modern TLS scanning tools
Include the Strict-Transport-Security header with a long max-age value
Set authentication cookies as Secure

2.3 Security Headers ^FAQ

Apply appropriate security headers to reduce the application attack surface and limit post exploitation:

Set a minimally permissive Content Security Policy
Limit the ability to iframe the application by enabling framing controls with X-Frame-Options or CSP frame-ancestors
Disable caching for APIs and endpoints that return sensitive data

2.4 Password policy ^FAQ

If password authentication is used in addition to single sign-on:

Do not limit the permitted characters that can be used
Do not limit the length of the password to anything below 64 characters
Do not use secret questions as a sole password reset requirement
Require email verification of a password change request
Require the current password in addition to the new password during password change
Store passwords in a hashed and salted format using a memory-hard or CPU-hard one-way hash function
Enforce appropriate account lockout and brute-force protection on account access
Do not provide default passwords for users or administrators

2.5 Security libraries ^FAQ

Use modern, maintained, and industry-standard frameworks, template languages, or libraries that systemically address implementation weaknesses by escaping the outputs and sanitizing the inputs

Example: ORM for database access, UI framework for rendering DOM

2.6 Dependency Patching ^FAQ

Ensure third-party dependencies are maintained and up-to-date, with security relevant updates having a severity score of "medium" or higher applied in line with your application patching schedule
Upon becoming aware of a Known Exploited Vulnerability affecting a third-party dependency, the patch should be prioritized
Where dependency patching or upgrades are not possible, equivalent mitigations should be implemented for all components of the application stack

2.7 Logging ^FAQ

Keep logs of:

Authentication events (success and failure)
Create, Read, Update, and Delete (CRUD) operations on application and system users and objects
Security relevant configuration changes (including disabling logging)
Application owner access to customer data (access transparency)

Logs must include user ID, IP address, valid timestamp, type of action performed, and object of this action. Logs must be stored for at least 30 days at no additional charge, and should not contain sensitive data or payloads.

2.8 Encryption ^FAQ

Use modern, maintained, and industry-standard means of encryption to protect sensitive data in transit between systems, and at rest in online data storages and backups

3 Application implementation controls

Control

Description

3.1 List of data ^FAQ

Maintain a list of sensitive data types that the application is expected to process

3.2 Data flow diagram ^FAQ

Maintain an up-to-date diagram indicating how sensitive data reaches your systems and where it ends up being stored

3.3 Vulnerability prevention ^FAQ

Train your developers and implement development guidelines to prevent at least the following vulnerabilities:

Authorization bypass — Example: Accessing other customers' data or admin features from a regular account
Insecure session management — Examples: Guessable token; a token stored in an insecure location (e.g. cookie without Secure and HttpOnly flags set)
Injections — Examples: (No)SQL injection, LLM / Prompt injection, XXE, OS command injection
Cross-site scripting — Examples: Calling insecure JavaScript functions, performing insecure DOM manipulations, echoing back user input into HTML without escaping
Cross-site request forgery — Example: Accepting requests with an Origin header from a different domain
Handling untrusted data — Example: Reusing data supplied by users within sensitive application contexts

3.4 Time to fix vulnerabilities ^FAQ

Produce and deploy patches to address application vulnerabilities that materially impact security within 90 days of discovery
For vulnerabilities with evidence of active exploitation, production and deployment of patches should be prioritized
Publish a security bulletin that details the vulnerability and its root cause if the remedy requires action from customers

3.5 Build and release process ^FAQ

Must use a version control system and consistent build process that generates provenance describing how the artifact was built (SLSA Build Level 1)
Sensitive application credentials and tokens should be stored separately from the application’s source code

4 Operational controls

Control

Description

4.1 Physical access ^FAQ

Validate the physical security of relevant facilities by ensuring the following controls are in place:

Layered perimeter controls and interior barriers
Managed access to keys
Entry and exit logs
Appropriate response plan for unauthorized access

4.2 Logical access ^FAQ

Limit sensitive data access exclusively to users with a legitimate need. The data owner must authorize such access
Deactivate redundant accounts and expired access grants in a timely manner
Perform regular reviews of access to validate need to know
Ensure remote access to customer data or production systems requires the use of Multi-Factor Authentication

4.3 Sub-processors ^FAQ

Maintain a list of third-party companies with access to customer data, and make it available to clients and business partners upon request
Assess third-party companies annually against the latest MVSP release

4.4 Backup and Disaster recovery ^FAQ

Securely backup all data to a different location than where the application is running
Maintain and test disaster recovery plans in concert with your incident response planning, at least annually or after significant changes

License

This document is public domain under CC0 1.0 Universal license.