Foreword  

A year ago, Okta was among the first technology providers to pledge our commitment to the US Cybersecurity and Infrastructure Security Agency (CISA)'s seven Secure by Design principles.

To CISA’s great credit, the Secure by Design voluntary pledge program has created strong momentum across the cybersecurity industry. Nearly 300 technology companies have since signed the pledge, with most having made significant strides in documenting their progress toward these goals.

One year on, we’re taking a moment to reflect and share an update on Okta’s progress.

As part of Okta’s commitment to Secure by Design, the default configuration for all new Okta tenants has been hardened as follows:

Under the Secure by Design pledge, Okta committed to measurable improvements in seven key areas identified by CISA. 

Okta’s full-year update for each of those initiatives is provided below.

1. Driving Adoption of Multi-Factor Authentication

Within one year of signing the pledge, demonstrate actions taken to measurably increase the use of multi-factor authentication across the manufacturer’s products.

Okta has built on its best-in-class record for customer adoption of multi-factor authentication (MFA) among both users and administrators of Okta Workforce Identity.

During the course of the one-year pledge, Okta had three primary goals:

1. Enforce MFA for all administrative access to management consoles,

2. Drive rapid adoption of high assurance, phishing-resistant authenticators such as Okta FastPass and FIDO2 passkeys,

3. Reduce customer exposure to weaker authentication methods.

Access to the Okta Admin Console or the Auth0 Management console now requires multi-factor authentication (MFA). 

Reaching this milestone required an exhaustive program that restricted the ability for administrators to create a single factor authentication policy for the Okta Admin console, and worked closely with a large number of customers to ensure that their existing policies could meet this requirement prior to enforcement.

We identified early in the process that some customers needed more time to meet this requirement - especially customers that allowed inline MFA enrolment, used inbound federation or relied on certain configurations of third-party Privileged Access Management solutions to access the Okta Admin Console. Okta released several innovations, such as authenticator claims sharing, to ensure MFA would always be applied, while maintaining a great experience for administrators. We thank these customers for taking this journey with us for the sake of our mutual security!

We’re also very pleased to see rapid growth in high assurance, phishing-resistant authentication factors during the course of the pledge. According to Okta’s Businesses at Work 2025 report, the volume of Okta FastPass authentications increased by 377% over 12 months. The total number of FastPass authentications backed by biometrics such as fingerprints or facial recognition increased by 288%. 

By contrast, the use of lower assurance authentication methods has reduced: security questions by 12% and SMS/Voice Call by 14%.

2. Reducing the use of default passwords

Within one year of signing the pledge, demonstrate measurable progress towards reducing default passwords across the manufacturers’ products.

As noted at the halfway point of the pledge term, Okta did not feel it necessary to pursue any further changes regarding default passwords. Where on-premise appliances, clients or agents require default credentials at installation, Okta enforces the required rotation of these credentials at first sign-in.

3. Reduce common classes of vulnerabilities

Within one year of signing the pledge, demonstrate actions taken towards enabling a significant measurable reduction in the prevalence of one or more vulnerability classes across the manufacturer’s products.

At the start of the pledge term, Okta committed to initiating a company-wide campaign to drive down exposure to a particular class of vulnerability.

Our first task was to classify vulnerabilities using a consistent methodology across the multiple products and services developed by Okta. 

Okta Product Security aggregated vulnerability data from all Auth0 and Okta products to create a single source of truth where vulnerability data could be normalized, analyzed, and classified.

This analysis painted a clear picture of what required more focus: a subset of vulnerabilities classed as Server Security Misconfigurations in the Bugcrowd VRT. 

For each shortlisted vulnerability, Product Security conducted “deep reviews” - technical investigations focused on specific vulnerability types, scoped for the entire codebase of Okta products, per their robust secure development practices. The reviews identified several issues that have since been remediated.

As part of this work, we developed and shared our methodology for reducing vulnerability classes. The methodology consists of distinct phases:

• Data Analysis - the aggregation, classification and trend analysis of vulnerability information.

• Scope Definition and Plan Execution - prioritizing results from data analysis based on frequency and risk, creating action plans, and executing and tracking remediation.

• Program improvements - creating standard trending metrics, vulnerability classification standardization, and shorter feedback loops.

This methodology was shared with the CISA Secure by Design working group. 

4. Drive improved customer patching hygiene

Within one year of signing the pledge, demonstrate actions taken to measurably increase the installation of security patches by customers.

Under the shared responsibility model for security, customers are accountable for maintaining up-to-date versions of client software. 

The CISA Secure by Design pledge promotes adoption of a “shared fate” approach to customer patching, where service providers play a more active role in steering customers toward better security outcomes. 

Okta has made measurable progress in our commitment to making it easy for customers to maintain up-to-date versions of client software.

During the course of the pledge, we embarked on a campaign to convince customers to upgrade their AD (Active Directory) or LDAP agents to versions that include additional security controls.

As background; some Okta Workforce Identity customers choose to delegate primary authentication to on-premise directories such as Active Directory (AD) or LDAP. In these hybrid identity flows, users signing in to access cloud resources provide credentials that are forwarded to an agent running on a host on the customer’s network to check their validity. 

In these configurations, the integrity of the customer’s Okta implementation relies, to some degree, on the customer’s Active Directory hygiene. A disproportionate share of incidents reported by customers to Okta Identity Defence  arise from an existing compromise of the customer’s Active Directory network.

In July 2024, Okta released a redesigned AD agent that adopted the “Demonstrating Proof of Possession” (DPoP) extension to OIDC, and added the same protection to the Okta LDAP agent from November 2024. While DPoP does not directly prevent a compromise of a Windows host, it can significantly reduce the blast radius for any compromise of the on-prem server(s) a customer uses to host these agents. 

Within 90 days of the release of the AD Agent, 44% of customers updated their agents to a version that included DPoP. A follow-up communications campaign, in which Okta mooted the possibility of removing support for versions that did not include these protections, drove adoption to 83%. The following version introduced support for end-to-end encryption.

We also observed that one of the primary instruments to achieving stronger customer patching hygiene is the availability and uptake of “automatic update” features in any given product. 

We have observed that while customers are very comfortable with automatic update mechanisms in software deployed to end-user clients, we face more resistance when customers are asked to enable automatic updates in client-side software deployed to servers. There is legitimate concern among CISOs - largely based on adverse events at other vendors - as to whether suppliers adequately test updates for every possible customer configuration prior to their release. 

During the term of the pledge, Okta ran direct-to-customer communications campaigns to assure customers of Okta’s strong record for stable updates. This drove a 6% increase in adoption. We continue to assess new ways of driving confidence in these controls. 

5. Publish a Vulnerability Disclosure Policy

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.

Okta has, as pledged, maintained 100% coverage of all Okta GA products in Bug Bounty programs and continues to publish a vulnerability reporting policy and disclosure policy.

From May 2024 to May 2025, Okta triaged 153 valid issues submitted via bug bounty programs and paid out $405,801 in total rewards.

During the term of the pledge, Okta ran several “bounty reward multiplier” campaigns in which vulnerability researchers were paid double, and in some cases triple the financial reward for finding vulnerabilities in specific products. This attracted a number of new security researchers to our bug bounty program.

6. Provide transparency on vulnerabilities

Within one year of signing the pledge, 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 that either require actions by a customer to patch or have evidence of active exploitation.

Okta has formalized our approach to sharing vulnerability information with customers during the term of the pledge.

We continue to remediate vulnerabilities discovered in Okta products in accordance with the contractual terms entered into with customers. Okta publishes CVEs when a vulnerability discovered in an Okta component requires action on the part of an Okta customer. Okta is a CVE Numbering Authority (CNA) authorized by CISA and MITRE to publish vulnerability information as CVE (Common Vulnerabilities and Exposures) bulletins. CVE bulletins for customer-installed Okta clients and agents are published online.

Okta has also revised its process for notifying customers of vulnerability information for a broader set of vulnerability types. All reported vulnerabilities are subject to both a technical assessment and an assessment of potential customer impact.

7. Deliver improved logging and monitoring for customers

Within one year of signing the pledge, demonstrate a measurable increase in the ability for customers to gather evidence of cybersecurity intrusions affecting the manufacturer’s products.

All Okta products provide mechanisms for administrators to troubleshoot access issues and for security teams to monitor for suspicious activity. 

At minimum, logged events include authentication and application access events, administrator and user actions, session context, and information on the source and target of an action. We recommend reading the table provided in our half-yearly update to learn more.

During the term of the pledge, Okta made measurable improvements to logging of both the Okta and Auth0 platforms, which are detailed below.

Okta System Log Improvements

Auth0 System Log Improvements

Final word

From the moment we signed the CISA Secure by Design pledge, Okta’s Product, Engineering and Security teams were enthusiastic about tackling this important work. The pledge was highly aligned with one of Okta’s four core values (“Always Secure, Always On.”). And every Okta employee is incentivized to lean into our security program under the Okta Secure Identity Commitment - our long-term initiative to lead the industry in the fight against Identity-based attacks.

One key benefit of CISA’s approach was in asking signatories to demonstrate progress. This meant that even in areas where our controls were mature, we could still challenge the business to demonstrate further improvements.

One of the more challenging conversations was around our “definition of done” for some of these programs. We observed that the quantum of effort required to close out the final 5-10% of coverage for any given control almost always required more resources than the first 90-95%. The support required to manage exception processes and the engineering required to handle edge use cases was the most taxing on our teams. 

Given the ambitious milestones we put forward, I’m very proud of all the people at Okta who collaborated, made concessions, and, in many cases, innovated to help meet our Secure by Design pledge goals.

As mentioned at the halfway point in this exercise, Secure by Design is never “done.” Okta is passionate about security - especially the security features all cloud applications need to support - to meet our larger, more ambitious goal of eliminating identity-based attacks.