Okta’s Ongoing Commitment to Secure By Design

Introduction

Okta is determined to raise the bar for cloud security.

In May 2024, Okta was one of the first technology providers to sign the CISA Secure by Design pledge. The pledge commits enterprise software companies to make a “good faith” effort to meet seven high-level Secure by Design goals within the course of a year.

This document assesses Okta’s progress against this pledge. 

To date, we have found it straightforward to demonstrate toward these goals in the vast majority of Okta products. We found it more challenging to be able to commit to achieving these goals in 100% of our products and operations. It has been a valuable exercise to hunt down and engineer solutions to those edge cases that prevent us from being able to state that we meet these goals without exception.

While technically at the midway point of the exercise, I want to stress that Okta’s commitment to security best practices does not end when the one-year mark is up in May 2025. Okta is engaged in a long-term initiative to lead the industry in the fight against Identity-based attacks - what we call the Okta Secure Identity Commitment. 

On that basis, we would not be opposed to CISA expanding its list of goals and making “Secure by Design” a multi-year program. At Okta, we have big ideas about the security features enterprise applications will need to have in place to handle emerging threats via IPSIE, a new open standard for identity in the enterprise. We stand ready to engage with CISA and our industry partners to shape a more resilient and secure future for cloud services.  

1. Drive 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."

Current State

Multifactor authentication is proven to be one of the most cost-effective and universally applicable security controls. 

Okta boasts a best-in-class record for adoption of multi-factor authentication among both users and administrators of the Workforce Identity Cloud. We publish statistics about MFA adoption, use, and performance via the Secure Sign-In Trends report. This report records the relative growth and decline in total MFA use and the use of specific authenticators. 

As of January 2024, 91 percent of administrators and 66 percent of users of Okta’s Workforce Identity Cloud signed in to an application using multifactor authentication. This represents close to a doubling of MFA usage since the months prior to the COVID-19 pandemic.

The passwordless, phishing-resistant sign-in methods supported in the Workforce Identity Cloud (Okta FastPass and FIDO2 WebAuthn) recorded the fastest growth as of January 2024. The growth of Okta FastPass was most impressive: this passwordless method climbed from 2% of users by the end of 2022 to 6.4 percent of users (and 13% of administrative users) in January 2024. 

There are several reasons Okta has historically outperformed the industry in terms of voluntary MFA adoption:

• Okta has made MFA accessible to all users:

  • Several sign-in methods (Okta Verify OTP and Okta FastPass) are available to all customers in the latest version of the Okta Workforce platform, Okta Identity Engine, released in 2022. These MFA methods are available to customers for use as a second factor irrespective of whether a customer is licensed for the Okta MFA solution.

• Okta is driving adoption of passwordless factors: 

  • Okta Identity Engine is a policy engine that allows for password-optional authentication flows for secure access to workforce applications. This frees up organizations to optionally phase out the use of passwords for designated user populations on modern devices.

  • Since February 2024, FIDO2 passkeys have been a first-class factor in the Okta Customer Identity Cloud (Auth0), providing customers an ability to offer a new primary authenticator to replace passwords in consumer-facing apps and websites.

Over the past 18 months, Okta has made several commitments that drive strong MFA adoption: 

• Okta no longer offers SMS as a default MFA method in new tenants for the Workforce or Customer Identity Clouds, in an effort to encourage customers to embrace stronger sign-in flows.

• Okta no longer allows administrators to create single-factor authentication policies for access to the Okta Admin Console (Workforce Identity Cloud) or Auth0 Management Console (Customer Identity Cloud). 

• Customer administrators now require MFA for access to the Okta Help Center, a service desk/support application for Workforce Identity Cloud customers.

Target State

Okta’s goal is to enforce MFA for all administrative access to internet-facing services within the term of the Secure by Design pledge. 

The MFA enforcement program for the Okta Admin Console commenced in September 2024 and is scheduled for completion by March 2025. 

This program is complex and staged to support the different mechanisms Okta customers use to access privileged accounts, including the use of federated identity providers and privileged access management solutions.

Okta’s longer term goal is to drive adoption of passwordless, phishing-resistant authentication for all administrative access. This method of sign-in dramatically reduces exposure to the most common forms of identity-based attacks. 

Current initiatives include:

• In-app notifications that nudge administrators signed in to the Okta Admin Console to enrol in phishing resistant factors.

• Dashboards in the Admin Console that help customers track adoption of phishing resistant authentication. 

• Updates to the Secure SignIn Trends report, which tracks the rate of phishing resistant adoption for administrators and end users.

Our other major initiative is the launch of additional features that extend phishing resistance across the user lifecycle, from enrolment through to authentication and recovery. These include pre-enrolled FIDO2 security keys to secure user onboarding as well as Identity Verification integrations that can be used to verify user identities using government-issued documents. 

2. Reduce the use of default passwords

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

Current State 

Default passwords present avoidable security risks.

All secrets generated in Okta cloud services are randomly generated. This includes customer tenant encryption keys, client secrets or JWK key pairs for application integrations, temporary user passwords and API keys.  

Where on-premise appliances, clients or agents require default credentials at installation, Okta enforces rotation of these credentials at first sign-in to the administrative console. 

Target State

There are no immediate changes required.

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.

Current State

Okta’s Product Security team performs security testing on all Okta products and triages vulnerability reports submitted by third parties.

In the interests of continual improvement, the team conducts large-scale studies of vulnerabilities reported across the Workforce and Customer Identity Clouds. Our latest study normalized this data against the Bugcrowd Vulnerability Rating Taxonomy (VRT) to generate trending metrics on critical and high vulnerabilities reported over time.

The Okta Product Security team uses the output from this analysis to make decisions about the tools, processes and campaigns required to address the most common root causes of vulnerabilities. 

The Okta Security Education capability within this team uses the findings, for example, to develop focus areas in training and awareness campaigns. The Okta Security Reviews team, meanwhile, are intermittently tasked with a “deep review” of a recurring bug class and make recommendations on how to prevent its occurrence across large numbers of development teams. 

This feedback loop has resulted in near eradication of a number of classes of vulnerabilities in Okta products. One example is Server Side Request Forgery. After multiple deep reviews, Okta’s Security Engineering function re-wrote an SSRF protection mechanism in 2020. Over the three years since, the number of SSRF bugs discovered has declined by an annual average of 47%. We have not (knock on wood) discovered or responded to any SSRF bugs in the Workforce Identity Cloud in 2024.

Target State

Okta Security now hopes to repeat this success with other vulnerabilities in the same category. Okta Product Security plans to initiate a campaign to drive down exposure to all vulnerabilities classed as Server Security Misconfigurations in the Bugcrowd VRT. The Server Security Misconfigurations category refers to 70+ vulnerability types. Many are troublesome because they tend to be difficult to discover or test for. 

We are currently in the planning phase, which will result in a target metric, development of a dashboard, and a range of actions, such as:

• Standardizing vulnerability categorization across product units, 

• Deep Reviews to discover any additional evidence of this vulnerability across Okta’s product portfolio,

• Updating Okta’s Secure Coding Guidelines to focus on this class of vulnerability,

• Education campaigns and champions program initiatives that target specific engineering teams,  

• Hunting for repetitive patterns that could be automatically detected using scanners, and

• Development and advocacy for preferred libraries or recommended “secure by default” values.

We will provide an update on our results at the end of year one of the pledge.

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.

Current State

Okta is committed to making it easy for customers to maintain up-to-date versions of client software, where it is required. We facilitate and encourage the ability for customers to automatically update client software without human intervention. 

Okta Workforce Identity Cloud customers can configure automatic installation of updates for Active Directory Agents and LDAP Agents that synchronize with on-premise identity services. The Okta Verify client on Windows can also be configured for automatic updates. 

Automatic updates remain optional, as many enterprise organizations prefer to test updates before they are applied in production. We offer customers the option of deferring or disabling automatic Okta Verify updates. 

Even in cases where customers have chosen to defer or disable automatic updates of clients, Okta notifies customers where a version of a client they are running is found to be vulnerable to a new attack. Okta registers vulnerability information with the national vulnerability database as a CVE and proactively identifies and contacts potentially impacted customers.

Administrators can check whether they are running the latest version of any given agent via notifications in the Admin Console. 

The Okta Verify client can be configured by administrators to automatically update on Android, iOS or MacOS using solutions from Okta’s Device Management partners. Users can auto-update the Okta Verify client or the Auth0 Guardian client downloaded from the Apple or Google app stores.

Target State

Okta is committed to delivering automatic updates on supported platforms. Our next goal is to ensure that no customer is left behind due to a lack of information or context about what software needs to be updated. We are exploring ways to elevate reminders about pending updates to more prominent positions in our administrative consoles - such as creating new task list items or “inbox” notifications.

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.

Current State

Okta is committed to providing opportunities for independent security researchers, customer red teams and other interested parties to discover and responsibly disclose vulnerabilities in our platforms.

Okta has a long-standing published Vulnerability Disclosure Policy and has maintained public bug bounty programs since 2016. Today Okta’s public bug bounty program includes the Workforce Identity Cloud, Customer Identity Cloud, Okta Privileged Access, Okta Workflows, Okta Access Requests, Okta Device Access, Advanced Server Access, the Okta support portal as well as client software (Okta Verify clients, Okta directory agents and the Okta browser plugin). 

Okta has provided financial rewards for over 400 issues submitted to the public bug bounty program since its inception, and paid out over US$440,000 in rewards.

Target State

Okta aims to maintain 100% coverage of all Okta products in our bug bounty programs. To achieve this goal, Okta recently added Okta Access Gateway and Okta Personal to a private bug bounty program, and promoted the Customer Identity Cloud (formerly Auth0) from the private program into Okta’s public bug bounty program. 

Okta is committed to adding new products to these bug bounty programs into the future.

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.

Current State

Okta addresses vulnerabilities discovered in Okta software and services in accordance with the contractual terms entered into with customers.

Further, Okta has published 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 at trust.okta.com/security-advisories/.

Target State

Okta commits to also publishing CVE bulletins for vulnerabilities where they meet the following conditions:

• Okta customers are required to apply a security update to mitigate the risk, or

• In the absence of a security update, Okta Security is aware of reliable workarounds or other mitigating actions a customer could take using third-party tools to address the risk posed by a vulnerability, or

• The vulnerability is subject to active exploitation in attacks on one or more Okta customers.

This approach balances the legitimate interests of Okta customers in understanding their exposure to risk, while protecting them from unnecessary risks and reducing the “ticket fatigue” burden that would be imposed if customer teams were held to account for risks they have no agency to mitigate. 

We recognize that this approach will result in some vulnerabilities never reaching the public domain, limiting opportunities for other parties to derive lessons from these bugs. With this in mind, Okta commits to providing greater transparency about vulnerabilities addressed in Okta services, where those methods of disclosure no longer impose risks for our customers. Okta recently published, for example, this short history of research into abuse of the Okta FastPass client as one approach to demonstrating this transparency, and presented on the same subject at Oktane 2024 in Las Vegas.

What is more important, in the eyes of many customers, is how we get the right security information into the hands of the right customer stakeholders in a timely fashion. Okta is committed to improving our methods of disclosing security-relevant information to customers. If you’re an Okta customer and haven’t provided your CISO/CIO and Security contacts to your Okta account representative, there is no time like the present!

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.

Current State

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. 

Logged events are typically available in administrative consoles and programmatically via APIs and log streaming (see table below). 

Okta is continually aiming to make log events more meaningful for security use cases. 

In August 2024 alone:

• Okta provided new ways to correlate events by session or by token in the Workforce Identity Cloud. A new rootSessionId field was added to a range of user events to help security teams correlate all actions performed within the context of a user session. A new rootTokenId field to a range of management API events to help customer security teams correlate all API calls that use a specific token.

• Okta provided administrators in the Customer Identity Cloud the ability to prioritize the streaming performance of security or risk-relevant event types (such as those relevant to detection and response) over other event types.

Target State

Okta has identified a range of additional improvements that can help customer security teams respond more effectively to suspicious events.

The roadmap for the Okta Workforce Identity Cloud includes:

• Okta will take Log investigator with Okta AI, currently in beta, to General Availability. Log Investigator provides customer admins an ability to construct System Log queries using natural language prompts. This aims to lower the bar for the domain knowledge required to work with System Log events.

• Okta will add a new changedDetails field to a range of configuration events to help customer security teams quickly identify the delta between former and current state after a configuration event.

• Okta will deliver optional System Log events for Workflows executions.

The roadmap for the Okta Customer Identity Cloud includes:

• Okta will deliver alerts and visual indicators for deviations from customer-defined thresholds set in the Auth0 Security Center.

• Okta will deliver Team-specific audit dashboards for configuration changes, administrative grants and current valid sessions. 

• Okta will deliver a visual session management dashboard for the Auth0 Management Console, along with the ability to revoke sessions. 

The roadmap for the Okta Fine-Grained Authorization includes:

• Okta will deliver log streaming for the new FGA product in the first half of 2025.

Conclusion

Okta applauds and thanks the US Cybersecurity and Infrastructure Security Agency’s efforts to promote Secure by Design among technology manufacturers.

We look forward to working with our customers, partners, peers and CISA to contribute further to achieving a stronger default level of security for all users.