Context: Multi-factor authentication is the greatest defense against password-based attacks such as credential stuffing and password theft. Any form of MFA has been shown to significantly reduce the success of such attacks, with more secure forms of MFA like phishing-resistant MFA offering even more protection against targeted attacks. Manufacturers should seek to increase MFA enrollment among their customers across the board, with an emphasis where possible of adopting phishing-resistant MFA and increasing enrollment by administrators.

Note: Other phishing-resistant forms of authentication, such as passkeys, meet this definition even if they are the sole form of authentication.

Example approaches towards achieving this goal:

• Enabling MFA by default for users and administrators (e.g., upon first registration, requiring users and administrators to configure MFA).
• Implementing “seat belt chimes” in products to nudge users towards enabling MFA. This could include, for instance, banners or interstitials notifying users or administrators that MFA is not enabled or suggesting that administrators enable phishing-resistant MFA.
• Supporting standards-based single sign-on (SSO) in the baseline version of the product, allowing customers to configure with their own identity provider that supports MFA.

Examples of demonstrating measurable progress:

• Publishing aggregate statistics of MFA adoption over time, broken down by user type (e.g., standard user, administrator) and MFA type (e.g., SMS, TOTP, FIDO2).
• Publishing a blog post describing measurable progress made, such as where MFA has been enabled by default, and highlighting where barriers exist.
• Participating in fora to advance long-term standards around MFA or authentication and demonstrating how these will result in measurable progress towards this goal.

Note: For this goal, manufacturers could demonstrate measurable progress either through results of customer behavior (such as a change in the use of MFA across their products), or through changes to the product itself (such as enabling MFA by default).

Context: Default passwords, which CISA defines as universally-shared passwords that are present by default across a product, continue to enable damaging cyberattacks. This item seeks to reduce the percent of exploitable default passwords in the wild in order to drive down attacks, with a particular focus towards internet-facing products. Default passwords should be replaced with more secure authentication mechanisms, as detailed in the examples below (and, preferably, MFA as detailed above). At the end of provisioning, only the customer should possess their authentication credentials.

Example approaches towards achieving this goal:

• Providing random, instance-unique initial passwords for the product.
• Requiring the user who installs the product to create a strong password at the start of the installation process.
• Providing time-limited setup passwords that disable themselves when a setup process is complete and require configuration of a secure password (or more secure authentication approaches, such as phishing-resistant MFA).
• Requiring physical access for initial setup and the specification of instance-unique credentials.
• Conducting campaigns or offering updates that transition existing deployments from default passwords to more secure authentication mechanisms.

Examples of demonstrating measurable progress:

• Publishing a blog post describing how the manufacturer is moving past (or has already eliminated) default passwords in various product lines.
• Publishing the number of products that have default passwords over time.
• Publishing details on the number of customers transitioned from default passwords to more secure authentication mechanisms.

Context: The vast majority of exploited vulnerabilities today are due to classes of vulnerabilities that can often be prevented at scale. Examples include SQL injection, cross-site scripting, and memory safety vulnerabilities, as detailed below. An effective way that software manufacturers can reduce risk for their customers is by working to reduce classes of vulnerabilities at scale across their products. Software manufacturers can pick one or more vulnerability classes for the pledge that they work to reduce over the course of the year. For more information on vulnerability classes that can be prevented at scale, see CISA’s Secure by Design Alert series.

Example approaches towards achieving this goal: 

• Consistently enforcing the use of parametrized queries to prevent SQL injection attacks.
• Adopting web template frameworks with built-in protection against cross-site scripting vulnerabilities.
• Developing a memory safe roadmap to transition to memory safe languages in a prioritized approach and writing new products in memory safe languages.
• Providing secure defaults for developers, such as by providing “building blocks” of secure functions and libraries that make it impossible (or significantly more difficult) to introduce a certain class of vulnerability.

Examples of demonstrating measurable progress:

• Publishing a blog on how the manufacturer has worked in the past year to significantly reduce the prevalence of one or more classes of vulnerability. This may include analysis of the root cause (CWE) of CVEs over time in the manufacturer’s products. CISA notes that successfully achieving this goal may actually lead to a short-term increase in CVEs as the manufacturer works to reduce that class of vulnerability — this should be regarded as a success if that class of vulnerability is reduced over the long run.
• Publishing a memory safety roadmap, or a similar roadmap for other classes of vulnerability.

Context: In line with the first Secure by Design principle, software manufacturers should take ownership of security outcomes of their customers – even after products are shipped. In addition to rooting out entire classes of vulnerabilities at the source, as detailed above, software manufacturers have the ability to make it easier for customers to install security patches – such as by offering support for security patches on a widespread basis to users and enabling functionality for automatic updates.

Example approaches towards achieving this goal:

• Providing functionality to allow automatic installation of software patches when possible and enabling this functionality by default, where appropriate.
• Offering support for security patches on a widespread basis to customers.
• In the cases where products are end of life and security patches are no longer supported, clearly communicate the expected lifespan at time of sale and, when the product reaches end of life, clearly communicate this to customers and invest in provisioning capabilities to ease customer transitions to supported versions.
• For cloud or SaaS products, applying patches so that the burden is not on customers to patch.

Examples of demonstrating measurable progress:

• Publishing aggregate statistics of patch adoption by product over time (e.g., the percent of users using various versions of each product).
• Publishing a blog post demonstrating actions made to foster greater deployment of security patches by users, or that otherwise reduce customers’ burden of patching.

Note: For this goal, manufacturers could demonstrate measurable progress either through results of customer behavior (such as a change in the percent of users on various versions of a product), or through changes to the product itself (such as by functionality for automatic software patches).

Context: Within one year of signing the pledge, publish a vulnerability disclosure policy (VDP) that authorizes testing by members of the public on products offered by the manufacturer, commits to not recommending or pursuing legal action against anyone engaging in good faith efforts to follow the VDP, provides a clear channel to report vulnerabilities, and allows for public disclosure of vulnerabilities in line with coordinated vulnerability disclosure best practices and international standards.

Context: Coordinated vulnerability disclosure has emerged as a mutually beneficial norm for engaging with security researchers. Software manufacturers benefit from receiving help from the security research community that can allow them to better secure their products. Security researchers receive authorization for testing under the policy, in addition to a clear channel to report vulnerabilities. For examples of vulnerability disclosure policy and safe harbor language, see CISA's Vulnerability Disclosure Policy Template and Disclose.io Policymaker.

Note: Due to the specific nature of this item, examples of achieving this goal are not included.

Examples of demonstrating progress:

• Publishing a public vulnerability disclosure policy in line with the above criteria.
• Publishing a machine-readable description of the vulnerability disclosure policy (e.g., a security.txt file) to better enable discovery by researchers.
• Publishing blog posts reviewing findings and lessons learned from the vulnerability disclosure policy.

Context: Demonstrate transparency in vulnerability reporting by including accurate Common Weakness Enumeration (CWE) and Common Platform Enumeration (CPE) fields in every Common Vulnerabilities and Exposures (CVE) record for the manufacturer’s products. Additionally, issue CVEs in a timely manner for, at minimum, all critical or high impact vulnerabilities (whether discovered internally or by a third party) that either require actions by a customer to patch or have evidence of active exploitation.

While not required for this goal, companies are encouraged to go above and beyond by filing CVEs for other vulnerabilities that do not meet these criteria for the reasons described below. Companies are also encouraged to explore additional ways to enrich their CVE records to help customers better respond to vulnerabilities.

Context: In addition to serving as a standardized way to communicate actions that customers should take to protect against vulnerabilities, timely, correct, and complete CVE records allow for public transparency in vulnerability trends over time. This benefits both individual companies and their customers, and the software industry more generally, allowing software developers to better understand the most pressing classes of vulnerabilities over time. Timely reporting of CVEs, particularly for ones with active exploitation, is essential to ensure that customers are aware of actions they should take. CISA cautions against interpreting the mere presence of CVEs as a negative sign, as the number of CVEs reported may rise in the short term as a software manufacturer implements Secure by Design principles – more comprehensive reporting of CVEs benefits everyone.

Note: Due to the specific nature of this item, examples of achieving this goal are not included.

Examples of demonstrating progress:

• Publishing CWE and CPE fields in every CVE record for the manufacturer’s products.
• Publicly describing the manufacturer’s policy for when a CVE is issued.

Context: It is essential that organizations have the ability to detect cybersecurity incidents that have occurred and understand what has happened. Software manufacturers can enable their customers to do so by providing artifacts and capabilities to gather evidence of intrusions, such as a customer’s audit logs. In doing so, software manufacturers embody the Secure by Design principle of taking ownership of their customers’ security outcomes.

Example approaches towards achieving this goal:

• As part of the baseline version of a product, making available logs related to areas such as:
  • Configuration changes or reading configuration settings;
  • Identity (e.g., sign-in and token creation) and network flows, if applicable; and
  • Data access or creation of business-relevant data.
• For cloud service providers and SaaS products, retaining logs for a set timeframe (e.g., 6 months) at no additional charge.
• In the cases where a product does not support the collection of these types of logs, the manufacturer publishes details on how customers can monitor and respond to cybersecurity incidents affecting their product.

Examples of demonstrating measurable progress:

• Documenting the manufacturer’s policies around providing logs and log retention (for cloud providers).
• Publishing a roadmap for adding or improving logging capabilities to products where they do not currently support collecting certain types of logs.