Duo Security Made MFA Ubiquitous. The Second Factor Is Still a Credential.

What Duo Security actually does, and does well

Duo earned its position honestly. It took multi-factor authentication out of the narrow world of high-security shops running hardware tokens and made it something a mid-market IT team could roll out in an afternoon. The push-notification model was the pivotal move: instead of asking a user to transcribe a rotating six-digit code, Duo sends an approve-or-deny prompt to an enrolled phone. That single interaction cut the friction of a second factor low enough that ordinary organizations adopted it as a default posture rather than an exception.

Around that core, Duo assembled a coherent platform. Duo Single Sign-On provides a SAML and OIDC federation layer so one authentication event covers many downstream applications. Device trust and the Duo Device Health application let policy consider the posture of the endpoint, not just the user, before granting access. Duo Trust Monitor surfaces anomalous authentication patterns for review. The factor menu is broad and current: push approval, time-based one-time passwords, phone callback, hardware tokens, and FIDO2/WebAuthn security keys and platform authenticators for phishing-resistant login. The measurable result is real, and worth acknowledging plainly: credential-stuffing and password-replay attacks that succeed against single-factor login fail against a well-configured Duo deployment, because the attacker who has the password still lacks the second factor.

None of that is in dispute. The question this article asks is narrower and structural.

The structural observation: every factor is still a credential

Multi-factor authentication improves security by requiring more than one proof of identity. But look at what each of those proofs is, at the architecture level. A push approval is bound to an enrolled device and a registration secret. A TOTP code is generated from a shared cryptographic seed provisioned at enrollment. A hardware token holds a seed or key. A FIDO2/WebAuthn authenticator is, precisely, a key: a private key held in a security key or platform secure element, registered as a public key with the relying party. A biometric unlock on the phone gates access to that stored key against a locally enrolled template.

Every one of these is a credential in the strict sense the disclosure uses: a stored secret, an enrolled key, or a provisioned template that persists between sessions and that must be defended, rotated, and revoked. Adding factors multiplies the number of credentials an attacker must defeat. It is a genuine and valuable increase in difficulty. But it does not change the category. The identity still reduces to "possession of, or access to, stored secret material." Enrollment, provisioning, device binding, and revocation are all present because the secrets are present. This is not a flaw in Duo; it is what MFA is. Strengthening the credential lattice and escaping the credential model are different projects.

What 19/388,580 proposes instead

United States Patent Application 19/388,580 describes identity that is not a stored credential at all. Instead of enrolling a secret and presenting it, a device or agent expresses identity as a trust slope: the cumulatively validated sequence of Dynamic Agent Hashes (DAHs) or Dynamic Device Hashes (DDHs) produced by successive, verifiable identity mutations. Each step is computed from the immediately prior step plus a source of non-exported unpredictability and a volatile, non-repeating salt, under a published update rule of the form DAH_t = H(DAH_{t-1} ∥ Ext(X_t) ∥ salt_t ∥ tag).

Two disclosed sources of that unpredictability matter for this comparison. In the hardware-anchor embodiment, a static hardware identifier (TPM, TEE, or SoC identifier) is combined with a per-epoch volatile salt. In the local-state embodiment, a bounded local state vector, drawn from device-observable signals such as monotonic counters, high-resolution timing deltas, scheduler jitter, and I/O micro-jitter, is passed through a strong extractor to yield a stable token, with stability-tuned projections so that small fluctuations preserve identity while genuine role or context changes intentionally flip a controlled subset of bits. A hybrid embodiment concatenates both. This is where the disclosure grounds its behavioral and continuity-based framing: identity derives from accumulated, locally observed behavior over time, not from a secret handed out at enrollment.

The verification is local and stateless. A receiver stores a previously trusted step and checks whether a presented successor is a valid on-slope descendant under policy-bounded continuity criteria. Because each step binds to the prior step and to non-exported unpredictability, an attacker who observes any single DAH cannot synthesize the next one: acceptance requires monotonic forward progression from a trusted state, and observation of one value confers no standing credential. Replay is rejected by non-reuse within a policy horizon; regressions and off-slope claims fail closed. Messages bind identity at both transport and payload layers, so a header DAH is screened for continuity before decryption and an embedded sender DAH is validated after it.

The disclosure adds the machinery a keyless model needs to be operable rather than merely conceptual: append-only mutation lineage logs with cumulative chain hashes and periodic anchors for tamper-evident provenance; sparse checkpointing and bounded proofs for memory-constrained and intermittently connected devices; delayed validation for high-latency links; entropy-anchor rotation with forward links for freshness; and quorum-based recovery, in which an agent that has lost its slope state rejoins the trust graph by aggregating signed attestations from previously trusted peers rather than restoring a backed-up secret. Biometrics appear, but in a specific and limited role: an optional privacy-preserving fuzzy extractor that contributes fresh local unpredictability during reseeding, where the biometric seed is never stored or exported in raw form. That is a materially different use of biometrics than gating access to a stored key.

The axis, stated fairly

Set the two side by side on the one axis that matters here.

Duo, like every MFA platform, defends identity by requiring possession of enrolled secret material, and it does so exceptionally well, with a broad factor menu that now includes phishing-resistant FIDO2 keys. Its trust anchor for a given login is the set of provisioned credentials, and its operational lifecycle is enrollment, provisioning, device binding, rotation, and revocation. That model has a single-point-of-compromise character wherever the stored secret can be extracted, phished into, or replayed, which is exactly why the industry keeps adding factors.

19/388,580 removes the standing secret from the authentication path entirely. There is no enrolled key to steal, no template to exfiltrate, no seed to phish, because identity is a validated behavioral trajectory reconstructed locally from continuity, not a credential retrieved from storage. The trade the disclosure is honest about internally is different in kind: it requires receivers to maintain trust-slope state and to run continuity, lineage, and recovery logic, and it is a filed disclosure describing an architecture, not a shipping product with Duo's integration breadth. This is not a claim that Duo is insecure. It is a claim that "add another factor" and "stop depending on stored factors" are structurally different answers, and the filing pursues the second.

Disclosure and enablement scope

The mechanisms above are disclosed at a level sufficient for a skilled implementer to build them: the update rule and its inputs, the extractor and stability-tuned projection of the local state vector, the two-stage transport-and-payload validation, the append-only lineage with cumulative anchors, delayed and sparse verification via bounded proofs, entropy-anchor rotation with forward links, quorum-based recovery, biometric-assisted reseeding via fuzzy extractors, and legacy interoperability through a segregated fallback adapter that never contaminates slope formation. The disclosure enumerates hardware-anchor, local-state, and hybrid embodiments and spans stateless fabrics, intermittently connected and delay-tolerant networks, memory-constrained endpoints, decentralized multi-domain systems, and cognition-native agent platforms, so the approach is claimed broadly across environments rather than tied to a single deployment.

Disclosure Scope

The inventive subject matter described here is disclosed in United States Patent Application 19/388,580. All statements about what the disclosed system does, its mechanisms, primitives, and guarantees, are grounded in that application. References to Duo Security, Cisco Duo, multi-factor authentication, push notifications, FIDO2/WebAuthn, and related products and standards are provided as external market and technical context to situate the disclosure; they describe third-party systems accurately at the architecture level and are not claims of United States Patent Application 19/388,580. Product and company names are the marks of their respective owners and are used here for identification and comparison only.