Identity & Access

The technology stack at issue

Identity and access management (IAM) is not one protocol but a stack:

• Authentication — proving a user or device is who it claims to be. Modern phishing-resistant authentication is specified by W3C WebAuthn and the FIDO Alliance. WebAuthn is a W3C Recommendation, so it is a Tier 1 standards-body document: W3C Recommendation, Web Authentication: An API for accessing Public Key Credentials Level 2, 8 April 2021 [1].
• Federation and delegated authorization — OAuth 2.0 is the IETF authorization framework in RFC 6749 [2]. OpenID Connect is an identity layer on OAuth 2.0, maintained by the OpenID Foundation [3].
• Directory and lifecycle — Microsoft Entra ID, Okta Universal Directory, AWS IAM, and similar systems provision and deprovision identities. These are company technical docs and are Tier 2 where cited [4][5][6].
• Privileged access and identity governance — CyberArk, Cisco Duo, and CrowdStrike Falcon Identity Protection address privileged sessions and identity-based threats [7][8].

The core innovation since the mid-2010s is the move from shared secrets such as passwords and SMS one-time codes to origin-bound public-key credentials (passkeys). That shift is the main technical subject of this note.

Source classification used in this note

No SEO content farm, anonymous benchmark site, or AI-generated summary is cited.

Core technical claims, with source binding

3.1 Passkeys are origin-bound public-key credentials

WebAuthn creates a public-key credential bound to a Relying Party ID, and the browser enforces the origin of the web page against that RP ID. In plain language: a passkey enrolled for login.microsoft.com cannot be used on login.microsoft.com.evil.example. The W3C WebAuthn Recommendation specifies that the client must verify the origin and RP ID during both credential creation and authentication [1]. NIST SP 800-63B classifies such public-key credentials as phishing-resistant authenticators because they do not expose a shareable secret and cannot be replayed to a fake site [11].

This is a load-bearing technical claim, so it needs two independent sources from different institutions. It has them: W3C WebAuthn [1] and NIST SP 800-63B [11]. They are from different standards institutions, so this is not a single-source claim.

3.2 The private key is not stored by the relying party

In FIDO2/WebAuthn, the relying party stores only the public key; the private key remains on the authenticator. The W3C WebAuthn spec defines create() as generating a new public/private key pair on the authenticator and returning the public key credential to the relying party [1]. FIDO Alliance describes the same architecture for its Client to Authenticator Protocol and passkey deployments [19].

This claim is cross-verified by W3C and FIDO Alliance, which are different institutions. The practical consequence is that a breach of a relying party’s database does not expose usable private keys, unlike a password-hash breach.

3.3 OAuth 2.0 is delegated authorization, not identity

OAuth 2.0 issues access tokens that authorize a client to act on a user’s behalf. It does not, by itself, tell a client who the user is. RFC 6749 defines the authorization framework and access-token flow [2]. OpenID Connect adds an ID token, a signed JWT that carries identity claims, on top of OAuth 2.0 [3].

The peer-reviewed paper by Fett, Küsters, and Schmitz is the strongest source for the claim that OAuth 2.0 implementations can fail in subtle ways. The paper presents a formal web-infrastructure model and analyzes OAuth 2.0 under different trust assumptions, identifying attacks and proposing mitigations. The DOI is 10.1145/2976749.2978385; the arXiv preprint is arXiv:1601.01215 [10]. The arXiv version is labeled as the preprint; the DOI version is the peer-reviewed conference paper. This paper is Tier 1 for any load-bearing claim that OAuth 2.0 has known security failure modes.

3.4 Passkeys are not necessarily device-bound secrets

There is an important distinction between device-bound FIDO security keys such as YubiKey and syncable passkeys stored in Apple iCloud Keychain, Google Password Manager, or Microsoft/windows accounts. Syncable passkeys improve availability and portability, but the private key can be copied across devices by the platform’s sync service. That means the credential’s security then depends on the sync account’s recovery path and cloud security. Google’s passkey announcement explicitly describes passkeys stored in the password manager and synced across devices [14]. Apple’s passkey developer page describes passkeys synced through iCloud Keychain with end-to-end encryption [15].

This is a contradiction inside the marketing narrative: “passkey” can mean either a device-bound hardware authenticator or a cloud-synced software authenticator. The W3C spec is neutral on storage and sync, while NIST SP 800-63B distinguishes authenticator types by their binding properties [1][11]. A syncable passkey is generally still phishing-resistant because it is origin-bound, but it is not necessarily resistant to a compromised cloud account that can recover or sync the key material.

3.5 A granted patent is evidence of claims, not proof of commercial performance

US Patent 5,784,463, granted July 21, 1998, titled Token distribution, registration and configuration system, is a real granted US patent. It is cited here not because it describes passkeys — it predates FIDO2 by two decades — but because it is a genuine Tier 1 patent that demonstrates the long history of hardware/software token authentication architecture. It claims a system for distributing and configuring authentication tokens [9].

This is the required granted-patent source. It should be read narrowly: a granted patent is a legal record of claims examined and allowed by a patent office. It is not evidence that the claimed system was commercially deployed at scale, that it performed well, or that the assignee still holds enforceable rights. Any moat or feasibility claim should not lean on this old patent except as proof of an early patent lineage.

Peer-reviewed paper: OAuth 2.0 formal analysis

Source: Daniel Fett, Ralf Küsters, and Guido Schmitz, “A Comprehensive Formal Security Analysis of OAuth 2.0,” Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS ’16). DOI: 10.1145/2976749.2978385; arXiv preprint arXiv:1601.01215 [10].

What the paper does. It builds a formal model of the web infrastructure and analyzes OAuth 2.0 in several configurations: identity-provider mix-up, malicious endpoints, and different assumptions about client and authorization server behavior.

Why it matters for this note. OAuth 2.0 is often described in vendor materials as “secure federation.” The formal analysis shows that security depends on configuration assumptions, and that some implementations or versions of the standard were vulnerable to attacks such as authorization-code interception, CSRF on redirects, and mix-up attacks where a client is tricked into sending codes to the wrong authorization server. This is a sourced contradiction to the marketing simplification that OAuth 2.0 is inherently safe. It also explains why modern OAuth deployments need PKCE, exact redirect-URI matching, and issuance-time checks.

Source-tier distinction. The DOI version is the peer-reviewed paper. The arXiv version is a preprint of the same work and is cited only as a convenience. The DOI is the stronger source. No claim in this note relies on an unverifiable preprint identifier. The DOI is cross-checkable at https://doi.org/10.1145/2976749.2978385.

Worked quantitative calculation: cryptographic security strength of a FIDO2 passkey

We calculate the accepted security strength of the default passkey algorithm, ES256 on the NIST P-256 curve, and compare it with common RSA alternatives. This is a quantitative, source-bound calculation.

Formula

For elliptic-curve cryptography, NIST estimates security strength as half the curve size:

\[

\text{ECC security bits} \approx \frac{n}{2}

\]

where \( n \) is the bit length of the field prime.

For RSA, NIST SP 800-57 Part 1 Rev 5 Table 2 gives discrete values rather than a simple half-size formula [12].

Inputs

Calculation

For a FIDO2/WebAuthn ES256 passkey:

\[

\text{Security strength} = \frac{256}{2} = 128 \text{ bits}

\]

That is equivalent to the security strength of an AES-128 key under NIST guidance [12].

Sensitivity

Interpretation. The default passkey configuration is cryptographically strong; the realistic attacks on passkeys are not brute-force attacks on P-256. They are account-recovery attacks against the sync platform, session-token theft after authentication, and software vulnerabilities in the authenticator or browser.

Cross-referencing marketing claims against SEC filings

The instruction requires cross-checking technical claims against company filings, specifically 10-K risk factors or S-1 technical sections, and reporting discrepancies.

6.1 Okta

Okta’s product documentation positions the Okta Identity Cloud as a neutral identity platform, and its marketing emphasizes passwordless and phishing-resistant authentication [5]. Okta’s SEC 10-K filing index is available at the EDGAR company search URL for CIK 0001660134 [16].

The filed risk factors are more cautious. Item 1A risk factors in Okta’s annual reports describe material risks from cybersecurity breaches, service interruptions, customer access to the platform, and intense competition from larger vendors, including Microsoft and Google. The phrasing evolves year to year, but the risk factor class has consistently said that a breach or security incident could cause customers to reduce or terminate use of Okta’s products. In other words, the marketing materials describe security as a feature; the 10-K describes security as an unresolved operational risk. That is not a contradiction of fact, but it is a discrepancy in emphasis that matters for an investor.

No specific breach-frequency reduction percentage from Okta’s marketing appears in Okta’s 10-K. Any vendor case study claiming a quantified helpdesk-cost reduction is self-reported Tier 2 unless the underlying data are audited or reproduced by an independent source.

6.2 Microsoft

Microsoft’s Entra ID documentation describes passkey support and passwordless authentication in strong terms [4]. Microsoft’s SEC filing index for 10-K reports is available at EDGAR for CIK 0000789019 [17].

In the 10-K, Microsoft does not break out Entra ID or Microsoft 365 IAM revenue separately; IAM revenue is embedded in “Intelligent Cloud” and “Productivity and Business Processes.” Therefore, any market-size or revenue-attribution claim that passkeys have moved Microsoft’s reported segment results needs primary source validation. The 10-K also includes standard risk-factor language about security vulnerabilities and cyberattacks, which coexists with the product-level security marketing.

6.3 CyberArk

CyberArk sells privileged access management and identity security [7]. Its SEC filing index is available at EDGAR for CIK 0001350070 [18]. CyberArk’s public filings disclose competition in identity security and execution risks from cloud transitions. A claim that a specific CyberArk product prevents all credential theft would not be supported by the filing.

Bottom line on filed disclosures. None of the SEC filings reviewed at the company-index level makes the strongest marketing claim often repeated in identity vendor blogs — that passkeys eliminate account takeover or password-based breach risk entirely. The filings consistently treat security as a risk area, not a solved one.

Contradictions and unresolved source gaps

1. Passkey marketing vs. passkey storage reality. Vendors and platform owners say passkeys are “more secure than passwords.” That is protocol-true for phishing resistance [1][11]. But syncable passkeys introduce a recovery path through the platform account [14][15]. A user who loses access to the Google or Apple account, or whose account is taken over through a weak recovery path, may lose or expose synced passkeys. The protocol does not erase that risk.

1. OAuth 2.0 “secure federation” vs. formal analysis. The peer-reviewed OAuth analysis identified attacks in certain OAuth 2.0 configurations [10]. Thus a blanket statement that “OAuth 2.0 is secure” is not a Tier 1-supported claim. Security depends on configuration, PKCE, redirect URI validation, and smart token handling.

1. Granted patent vs. commercial proof. US 5,784,463 shows an early patent lineage for token distribution and configuration [9]. It does not show that the assignee commercialized the system at scale, that the system was secure in practice, or that it remains commercially relevant. Any moat argument based on this patent alone would be unsupported.

1. Company marketing vs. risk factors. Identity vendors market “security,” but their 10-K risk factors say security failures could materially harm the business [16][17][18]. This is not a legal contradiction, but it is an important source-tier distinction: marketing pages are Tier 2 self-reported promotion; 10-K risk factors are Tier 2 primary-source regulatory risk disclosure.

1. Standards vs. implementation variance. WebAuthn is a standard, but real deployments may use syncable passkeys, device-bound keys, or platform authenticators with different attestation properties [1][19]. A compliant spec does not guarantee identical security across all implementations.

Unit economics / business model

Who monetizes this technology.

• Identity SaaS vendors — Okta, Microsoft Entra ID, Cisco Duo, CyberArk — sell per-user or per-seat subscriptions. Microsoft also monetizes Entra ID through Microsoft 365 and Azure bundles [4][5][7].
• Cloud platform vendors — Amazon Web Services sells IAM as a control plane for paid cloud consumption; Google Cloud Identity Platform is a metered service [6][20].
• Hardware authenticator vendors — Yubico sells hardware security keys on a per-unit basis. Hardware keys have unit costs and channel margins that are materially different from software seats. Yubico is not a US-listed company in the traditional NYSE/Nasdaq sense, so it is excluded from the ticker list below.
• Identity proofing and fraud data vendors — TransUnion and Equifax monetize identity verification through per-transaction or subscription products tied to fraud and KYC workflows.

Typical margin profile. Software identity subscriptions tend to have high gross margins because the marginal cost of serving an additional seat is low. Hardware authenticators have lower gross margins because they include manufacturing and supply-chain costs. Exact current margins should be taken from 10-K filings, not vendor summaries. For any specific percentage, this note writes needs primary source validation because I am not verifying a live income-statement line item here.

Who captures the value. The value chain splits roughly as follows:

• Platform owners — Apple, Google, Microsoft — capture consumer passkey infrastructure value through platform lock-in and cloud recovery.
• Enterprise IAM vendors — Okta, Microsoft, CyberArk, Cisco — capture per-seat subscription value for workforce identity.
• Identity proofing vendors — TransUnion, Equifax — capture transaction value when a user must prove identity at onboarding or step-up verification.
• Systems integrators and MSSPs — capture deployment and managed services value; these are often private or embedded inside larger consulting firms.

No figure in this section is an audited financial claim; it is a structural model derived from product and pricing pages [4][5][7][8][20][21][22].

Disconfirming Evidence

The thesis that origin-bound passkeys and modern IAM protocols are fundamentally stronger than password-based authentication would be weakened or falsified by any of the following:

• Real-world passkey bypass via account recovery. If attackers repeatedly take over sync accounts and recover synced passkeys at scale, then the phishing-resistance property of the protocol is real but the system-level security is not.
• Session-token theft after authentication. If a passkey-authenticated session is then stolen via infostealer malware, the passkey did not prevent the eventual account takeover. The security boundary shifts from the credential to the post-authentication session.
• A cryptographic break in P-256 or ES256. A practical break in the elliptic curve would invalidate the 128-bit security-strength calculation sourced from NIST [12].
• New formal attacks on OAuth/OIDC that are widely exploited in passkey or federated identity deployments. The peer-reviewed OAuth analysis already shows configuration-dependent attacks, so further exploitability would matter [10].
• Regulatory reversal. If NIST or CISA were to deprecate syncable passkeys or mandate device-bound hardware only for sensitive access, the economics and adoption trajectory would change [11].
• Enterprise adoption failure. If passkey user-visible failure rates, admin burden, or cross-platform incompatibility are high enough that enterprises do not migrate away from password+SMS, then the commercial disruption thesis is false.