The native floor

The native floor is the rung the router reaches when every external method is unavailable. It exists because a ladder without a floor doesn’t close: a correlated outage that takes every external rung out at once produces an authentication gap the router cannot resolve. The floor closes that gap, for the subset of the population enrolled in a locally-verifiable factor.

This page describes what the floor authenticates against, how users get enrolled, and the gating policies that determine who the floor actually covers.

What it authenticates against

Native authentication verifies a presented factor against credential material held in the deployment’s credential store. In the default database-resident topology, that material lives in the instance’s local database alongside the canonical view; no arrow leaves the instance during a floor authentication. In externalized-keystore topologies, verification may require a keystore operation — the explicit tradeoff a deployment selects in exchange for stronger credential custody.

Four factor shapes are supported, each with different enrollment, verification, and security properties:

WebAuthn. Per-user public keys registered with Authonomy. The private material lives in the user’s authenticator (a platform authenticator on a device, or a roaming hardware key) and never leaves it. The instance verifies the authenticator’s signed assertion against the public key in the canonical view. This is the strongest factor the floor supports and is the recommended shape where deployment policy permits.

TOTP. Time-based one-time passwords against a shared seed held in the canonical view, encrypted at rest. Useful where WebAuthn enrollment is impractical for a population.

Password. A user-set password verified against a hash held in the canonical view. The hash uses a modern memory-hard password-hashing function with per-user salt and a configurable work factor; the instance enforces rate limiting and progressive lockout against brute-force attempts. Password is the weakest of the three user-enrollable factors but the most accessible — no app, no hardware key, no enrolled device. Often configured as the available factor for populations on shared devices, registers, or kiosks.

Administrative credentials where configured. Break-glass credentials held at the instance for named administrative identities, used when the authentication path itself is being recovered.

A subject whose configured method is an external IdP flow and who has not been enrolled in any locally-verifiable factor cannot authenticate against the floor, because no credential material exists at the instance to verify against. This is the enrollment boundary.

How enrollment happens

Floor credentials are enrolled with Authonomy, not pulled from the customer’s identity provider. The default enrollment surface is just-in-time at first authentication: when a user first authenticates through Authonomy via any external method, the instance prompts the user to register a floor factor before completing the authentication flow.

The trust chain is structurally clean. The user has just authenticated against a strong factor at the upstream provider; that assertion is fresh and bound to the request. The instance treats the upstream assertion as proof of identity for enrollment, presents the appropriate enrollment ceremony (WebAuthn registration, TOTP setup, or password creation), and writes the resulting credential material to the credential store. Once enrolled, the user’s authentication completes normally; subsequent authentications via the external method route through Authonomy as before, with the floor factor sitting ready against severance.

Enrollment policy has four configurable axes:

Required versus optional. Required-at-first-login means the user cannot complete authentication without registering a factor; the deployment guarantees floor coverage for everyone who has authenticated through Authonomy at least once. Optional means the user is prompted but can defer.

Population scope. Configured per group or per attribute. A deployment can require enrollment for populations that need site-severance coverage and leave it optional for populations that don’t.

Factor choice. Whether the user picks among supported factors or the deployment dictates one. Most deployments offer WebAuthn and TOTP and let the user choose; password is offered alongside in deployments that need it for accessibility reasons.

Re-enrollment cadence. Lost devices, expired credentials, or compromised factors trigger re-enrollment. Recovery routes through the upstream provider — the user authenticates at the IdP, falls back into the enrollment hook, registers a fresh factor — and requires the credential store to be reachable. Periodic re-enrollment (annual, biannual) can also be configured for specific populations.

Coverage builds with usage

Three properties of the just-in-time enrollment model are worth naming:

Coverage builds with usage. A user who has not yet authenticated through Authonomy is not floor-authenticable, regardless of provisioning state. Their identity is in the canonical view (synced from the upstream authority), but they have no credential material registered.

Day 1 coverage requires deliberate effort. A deployment that needs every newly-provisioned user to be floor-authenticable from their first day pairs just-in-time enrollment with a forced first-login workflow at onboarding — typically an automated email or in-app prompt directing the user to log in and complete enrollment before they begin work. Without that pairing, new users are coverage gaps until they happen to authenticate through Authonomy.

First login during severance is an edge case. A user whose first authentication coincides with a severance from the upstream IdP cannot complete the upstream step, so cannot reach enrollment, so is not floor-authenticable. The population this affects is small in steady-state operation, but it’s named here for completeness.

What the floor covers

Floor authentication is gated by two independent controls. Both must be satisfied for a user to be floor-authenticable:

Canonical-view scope. Which subjects the instance’s canonical view contains. A deployment with a defined operational population at each site (the staff of a store, the operators of a facility) typically scopes the view to that population.

Factor enrollment. Which subjects within the canonical view’s scope have registered a locally-verifiable factor. Enrollment happens just-in-time as described above; subjects who haven’t authenticated through Authonomy yet have no credential material.

The floor’s coverage is the intersection of “in scope” and “enrolled.” Populations outside that intersection are not covered, and the deployment should be explicit about the tradeoff. A deployment selects the enrollment policy that produces the coverage shape the business needs — typically narrow enrollment for continuity-critical populations, broad enrollment for administrative and break-glass identities, or universal enrollment where the regulatory or operational posture requires it.

What the floor does not do

Three explicit non-claims:

It does not replace the authoritative identity provider. The floor authenticates against a replica; it does not author identity-lifecycle events. A user provisioned during a severance does not become floor-authenticable until the severance ends and the sync engine catches up.

It does not authenticate users without enrolled credential material. A user whose configured method is an external IdP flow and who has not enrolled in a locally-verifiable factor will fail authentication when the ladder resolves to the floor.

It does not displace external methods when they are healthy. The floor is the last rung. The router reaches it only when every higher-priority rung is unavailable, or when an operator has explicitly activated it for a defined scope.