Update — 20 July 2026. The public beta is open, and the hosted account plane listed under roadmap below has since shipped:
account.consystence.comis live in production, sign-in provisions a personal sandbox tenant, and licensing and billing are built. This site now leads with Start free. The offline identity design below is unchanged, so we have left the post as written.
It is 3am at a remote pump station. The link to the cloud has dropped, a transfer pump has thrown an alarm, and an operator walks up to acknowledge it and start the standby. A cloud-only login asks them to wait on a round-trip that is not coming — the identity provider is in another state. The plant needs a decision now; the sign-in is over the horizon.
The usual fixes are a shared password taped under the keyboard, or a break-glass account that skips identity altogether. We refused both. A Consystence site issues its own identity, so an operator can sign in and acknowledge an alarm with no internet at all. The same endpoints still accept a cloud single sign-on or a machine key — one selector picks the scheme per request.
Two authorities, three schemes
Identity has two authorities, not one. When the link is up, the cloud is authoritative: single sign-on through Microsoft Entra External ID over a hand-rolled OIDC authorisation-code flow with PKCE, built against the discovery document, not a turnkey library. When the link is down, the site is authoritative — on an OT site, the load-bearing path. The cloud is the enhancement; the offline floor has to hold.
Three schemes serve those authorities: the cloud sign-on, a site-issued PIN login for offline operators, and an X-Api-Key credential for machines. Endpoints do not choose between them. One policy selector reads each request and forwards it — a key header to the key handler, a bearer token to the cloud validator or the site one, routed by its issuer. The issuer is read only to route; full cryptographic validation still runs downstream, so a forged issuer fails closed to a 401, never a bypass. Every endpoint carries one authorisation policy over all three — the same bet as one device model, many vendors: the variation sits at a thin seam; nothing above learns the difference.
The login that needs no link
The offline path is the one that earns the post. An operator signs in with an email and a numeric PIN — a site-local credential, separate from the cloud account — and the site server mints a JWT itself, signed RS256 with an RSA key held encrypted at rest in the site’s own database, served through a local JWKS, rotated with the previous key kept for overlap. No cloud provider issues that token, and none validates it; the site is its own issuer. The PIN is enrolled once from an authenticated session; every login after that needs no link.
It is built like a credential that matters. The PIN is six digits or more, hashed, with lockout after five failed attempts and uniform invalid credentials responses that never reveal whether an account exists. Refresh tokens carry reuse detection — replay a revoked one and every session for that user is revoked at once. The link being gone is no excuse for the login being weak.
Presence, not authority
If a site can mint its own logins, isn’t that a back door? No — and the limit is the feature. A site-PIN token asserts one thing: that this person is physically present and authenticated at this site. It carries no org_role and no org_slug — the login and its refresh both stamp them null by design — so it lets an operator operate, acknowledge the alarm, but grants no organisation-level or tenant-admin authority, and anything that reads a role denies on its absence. This is advisory by design wearing a different hat: rather than ask you to trust that a local login will not overreach, we built one that does not.
What ships, and what is next
To be precise about the line:
- Shipped: the three schemes — Entra External ID sign-on over hand-rolled
OIDC/PKCE, the site-issued PINJWTwith localJWKS, key rotation and refresh-token reuse detection, and theX-Api-Keymachine credential — behind one policy-scheme selector, with tests over the selection matrix and cross-scheme claim parity. - Roadmap: the hosted account and self-serve sign-up — a managed tenant per organisation — is proven on a workshop rig, not in production; the sign-up-to-provisioned-org flow is not yet end-to-end, and licence and billing remain to build. All of it is future work, and we label it as such.
And the limits, stated straight. The schemes and the selector are tested — but on the bench, not yet through months of dropped links with operators leaning on the offline path. The hosted, at-scale identity around them is not in production: this site still leads with Request a demo, not Start free, because that account host is not live yet. The authentication design is shipped; the identity product is still being built.
Identity, like control, has to live where the plant lives. The cloud can vouch for who you are when the link is up; when it drops, the site has to know on its own.