BetterSign™ Become a design partner

BetterSign for Organizations

Replace your identity provider. Keep nothing to steal.

A self-hosted, password-free org IdP on provenance logs.

Your company runs its own BetterSign sign-in service. Every employee signs in with a hardware key on their phone, and no password exists anywhere, so there’s nothing to phish, reset, spray, or leak. Start beside Okta or Entra, then replace them one group at a time.

Employees authenticate with a device-bound WebAuthn credential on their phone. Each app checks it against the employee’s provenance log and the organization’s own quorum-signed log. A protocol host speaks OIDC, SAML 2.0, SCIM 2.0, CAEP and short-lived certificates, and a single Rust core does every cryptographic check.

  • No password database, and no password-reset desk
  • Joiners, movers, and leavers reach every app within seconds
  • Runs beside your current IdP, with no flag day
  • Phishing-resistant only: device-bound passkeys (BE=0), no OTP or push
  • Directory = org provenance log, m-of-n admin quorum in HSM/KMS
  • Coexists with Okta, Entra, Ping, Keycloak, and AD FS
Become a design partner See the evaluation path

Your directory becomes a signed logbook, and your logins become keys on a phone.

In development

BetterSign for Organizations is being built with a small group of design partners. Android sign-in works end to end in test builds; iOS is next. If you run Okta, Entra, Ping, or Keycloak and want to pilot it, talk to us.

Benefits

What your company gets.

Okta and Entra already offer passkeys. These are the differences that matter.

∅

No credential database to breach

The sign-in service holds nothing that proves who someone is. A stolen database or server can’t produce a login that a self-checking app will accept.

Postgres holds protocol state only: clients, codes, refresh families, SCIM cursors. Losing it logs people out; it doesn’t lose who works there.

⛓

A directory that can’t be quietly edited

Every hire, role change, and departure is a signed entry that needs several admins to approve. Auditors read the log instead of trusting screenshots.

Membership, roles, and device approvals live in the org provenance log. An m-of-n lock script enforces the admin quorum, so a compromised host cannot add itself an admin.

⚡

Leavers lose access in seconds

When HR marks someone as gone, every app hears about it within seconds and sessions end. Certificates are short-lived, so there’s nothing left to chase.

The org node streams new log heads to validators; the host revokes refresh tokens, sends CAEP session-revoked, and deprovisions through SCIM out.

☎

No more “reset my password”

There’s no password, so there’s no reset, and no help-desk call for an attacker to talk their way through. A lost phone is handled by identity proofing and admin approval.

Recovery is an org-quorum key rotation on the employee’s work VLAD after policy-selected identity proofing. It is a signed, visible log entry.

◇

One identity for every door

The same work identity signs people into web apps, servers, VPN and Wi-Fi, and lets services prove who they are to each other.

One work VLAD drives OIDC/SAML SSO, OpenSSH user certs, EAP-TLS, PKINIT, and SPIFFE SVIDs from vlad-ca.

⇋

Partner access without federation projects

A partner’s staff prove who they are with their own company’s log. You decide which roles you accept; there’s no per-partner setup project.

/partners/<org-vlad> in your org log replaces per-pair SAML federation; partner membership is checked against their org log.

⌂

You run it, and it outlives us

The service and the network it depends on run in your environment. Sign-in keeps working if the internet’s public network, or Cryptid, is down.

The org node pins your org and employee logs, optionally on a private network. Logs verify without any Cryptid service.

↔

Built for the stack you have

Your team customizes it in the language they already use, and the security-critical code is written once and shared by all of them.

Go, Java (Keycloak + Spring), C#/.NET (OpenIddict + Entra), and Python editions over one Rust core, gated by a shared conformance suite.

How sign-in works

A phone tap your apps can check for themselves.

An app sends the employee to your company’s sign-in page. They approve on their phone, and your service checks that the key is theirs, they still work there, the phone is approved, and they’re allowed into this app.

The app redirects to id.acme.com (OIDC authorize or SAML AuthnRequest). The browser runs a WebAuthn hybrid ceremony with the phone. The validator checks the assertion against /keys/webauthn/<credId>, enforces BE=0, membership, device approval, and policy, then the host issues an HSM-signed token.

  1. An app (Salesforce, Slack, your intranet) sends the employee to your sign-in page.

  2. The employee scans the code with their phone and approves with their face or fingerprint.

  3. Your service checks the signature, their membership, their device, and your policy for that app.

  4. The app receives a signed login with roles and groups. Sensitive apps can re-check it themselves.

What you run

Protocol hostOIDC · SAML · SCIM · CAEP · login pageGo · Java · .NET · Python
ValidatorChecks every login against the logs and your policyRust core, one implementation
Org nodeKeeps your company’s and employees’ logs close and currentPrivate network optional
Certificate issuerShort-lived SSH, VPN, Wi-Fi, and workload certificatesvlad-ca

Admin keys sit in your HSM or KMS. The database holds sessions only, never credentials.

Evaluate, then replace

Move in stages. Stop at any one.

You don’t rip anything out to try BetterSign. Each stage runs alongside what you have, rolls out one group of people at a time, and has a clear way back.

0

Prove it in a sandbox

A few weeks · IT team only · no production change

Steps

  1. Stand up the org node, validator, and reference host in a test environment.
  2. Create your org log and admin quorum, with keys in a test HSM or KMS.
  3. Enroll 5–10 IT staff on their phones (Android 14+ today).
  4. Connect one internal test app over OIDC or SAML.
  5. Run the conformance harness and try to break it: replay, wrong origin, revoked device, terminated member.

You measure

  • Sign-in success and time to sign in
  • Enrollment time per person
  • Seconds from “terminated” to access gone
  • Your security team’s review findings
Passwords
Untouched
Your IdP
Untouched
Way back
Turn the sandbox off
1

Add it as a factor

Pilot group on real apps · your IdP still in charge

Steps

  1. Register BetterSign with your IdP as a phishing-resistant factor (see the table below).
  2. Pick a pilot group, for example IT plus one willing team, and push the app with your MDM.
  3. Feed joiners and leavers from HR or your IdP by SCIM, and approve enrollments with identity proofing.
  4. Require the BetterSign factor for the pilot group on a few real apps.
  5. Expand the group as the numbers hold.

You measure

  • Phishing-resistant coverage of the pilot group
  • Help-desk tickets per user, against your baseline
  • Lost-phone recoveries and how long they take
  • User satisfaction
Passwords
Still exist
Your IdP
System of record, first factor
Way back
Remove the factor from policy
2

Make it the only way in

Migrated users have no password at all

Steps

  1. Route migrated users to BetterSign as the upstream identity provider; your IdP keeps issuing tokens to apps.
  2. Remove password sign-in for those users and delete their password hashes.
  3. Switch SSH to short-lived certificates and VPN / Wi-Fi to certificate login.
  4. Subscribe key apps to instant session-revocation events.
  5. Migrate group by group, starting with the people phishing targets most.

You measure

  • Password hashes deleted
  • Password-reset tickets for migrated users (target: zero)
  • Leaver propagation time across apps
  • Sign-in success across devices
Passwords
Gone for migrated users
Your IdP
Token issuer; trusts BetterSign upstream
Way back
Route the group back and re-issue credentials from your IdP
3

Retire your old IdP

BetterSign is the directory and the identity provider

Steps

  1. Make the org log the system of record; HR feeds it directly by SCIM.
  2. Point apps at BetterSign over OIDC and SAML, and provision them by SCIM out.
  3. Move workstation logon (Windows, macOS, Linux), the hardest step, last.
  4. Put legacy password-only apps behind managed secrets no person ever sees.
  5. Retire the previous IdP one business unit at a time, or keep it downstream for apps that can’t move.

You measure

  • Apps and users served directly
  • Remaining places a person types a password
  • Audit evidence pulled from the log
  • IdP licence and help-desk cost removed
Passwords
Gone
Your IdP
Retired, or a downstream app
Way back
Keep the old IdP downstream until you’re sure

How BetterSign connects to your current IdP

Your IdPStage 1: as a factorStage 2: as the primary sign-in
Microsoft Entra IDExternal Authentication Method providerFederate the domain to BetterSign (SAML / WS-Fed)
OktaOIDC identity provider used as a factorRouting rule sends migrated users to BetterSign
PingPingFederate adapter or OIDC IdPPrimary authentication source
KeycloakAuthenticator in the browser flow (Java edition)BetterSign is the only step; the org log becomes the user store
AD FSAdditional authentication providerReplace AD FS with BetterSign (.NET edition)

Coverage

Every place a password lives today.

“Password-free” only counts if it’s everywhere. Most of the value (web sign-in, SSH, VPN) comes first; workstation logon comes last.

Where passwords liveWhat replaces themWhen
SaaS and internal web appsSign-in over OIDC or SAMLEarly
Apps behind Okta or EntraYour IdP trusts BetterSign as a factor or upstream IdPEarly
SSH to serversShort-lived SSH certificates after a phone approvalEarly
Help-desk password resetsIdentity proofing plus admin-quorum recoveryEarly
Break-glass admin accountsQuorum keys in an HSM and sealed hardware tokensEarly
VPN and Wi-FiCertificate login (EAP-TLS) with short-lived certificatesNext
Service accounts and workloadsWorkload certificates (SPIFFE) or mutual identity TLSNext
Legacy password-only appsA managed secret that’s generated, injected, and rotated; no person sees itNext
Linux workstationsPAM module that asks for a phone approvalNext
Windows logon and Active DirectorySmart-card-style certificate logon; AD rolls the old password awayLast
macOS logonPlatform SSO with a BetterSign extensionLast

The employee lifecycle

Joiners, movers, leavers, lost phones.

＋

Joiner

HR adds them. They get an invite, install the app, prove who they are, and an admin approves. No temporary password, ever.

SCIM in → pending /members slot → app creates work VLAD + WebAuthn key → identity proofing → quorum appends active → SCIM out.

⇄

Mover

A role change is one signed entry. Apps update their access right away instead of waiting for a token to expire.

Org-log entry → claim re-mapping → SCIM updates → CAEP token-claims-change.

−

Leaver

Marked as gone in the log, and every app knows within seconds. Sessions end, accounts close, and certificates simply run out.

status: terminated → change feed → refresh tokens revoked, CAEP session-revoked, SCIM deprovision, vlad-ca stops issuing.

↻

Lost phone

Another of their devices vouches for the new phone, or IT recovers them after identity proofing. Every step is in the log.

Enrolled device signs the new key, or the recovery quorum rotates the work VLAD after proofing; /devices approval required.

Editions

Four languages, one core.

Enterprises customize claims, policy, branding, and connectors in the language their platform team already knows. Every edition must pass the same conformance tests before it ships.

Go

Standalone daemon

The reference implementation. A single binary with a Helm chart, full SCIM in and out, session events, and a Linux PAM backend.

For cloud-native teams, or anyone replacing an IdP outright.
Java

Keycloak extension

Keep Keycloak. BetterSign becomes its authenticator and its directory, plus a Spring Boot starter for your apps.

For JVM shops, banks, and government.
C# / .NET

Microsoft estate

An Entra External Authentication Method, AD certificate logon tooling, and an AD FS replacement.

For organizations on Entra, AD, and Windows fleets.
Python

Integration kit

App middleware for Django, FastAPI, and Flask, plus HR connectors (Workday, SuccessFactors, BambooHR), SaaS provisioning, and an admin CLI.

For every edition’s integrations.

Questions

For your security and IT teams.

Is it available today?

It’s in development with design partners. Phone sign-in works end to end on Android in test builds, and iOS is next. Design partners start at Stage 0 and help shape Stage 1. Get in touch if you’d like to be one.

Do we have to replace Okta or Entra to try it?

No. Stages 0 and 1 leave your IdP in charge; BetterSign is added as a phishing-resistant factor for a pilot group. You only move further if the results justify it, and you can stop at any stage.

What happens if the BetterSign server itself is compromised?

It can’t add people, change roles, or forge a login, because those need the admin quorum and the employee’s phone. It could issue tokens to apps that trust it blindly, which is why we recommend that your most sensitive apps check each login themselves. Token-signing keys stay in your HSM.

Can the company impersonate an employee?

Only by rotating that employee’s keys, which is a signed entry in a log the employee can read, and their app tells them. Recovery and offboarding are possible; quiet impersonation isn’t.

Which phones and computers does it need?

Today: Android 14 or later. iOS is in progress. Computers sign in by pairing with the phone over Bluetooth; for machines without Bluetooth, a USB adapter or a FIDO2 security key enrolled as a second credential keeps sign-in phishing-resistant.

Is it self-hosted?

Yes. You run the sign-in service and the network it depends on, optionally on a private network, so employee logs don’t have to be public. Whether we also offer a hosted option for smaller companies is still open; tell us if you’d want one.

How is this different from the BetterSign Passwords product?

BetterSign Passwords is for individuals, keeping their own saved logins on their phone. BetterSign for Organizations removes passwords from your company entirely. For legacy apps that still demand one, it uses managed secrets that no employee ever sees.

Start with Stage 0.

A sandbox, your IT team, one test app. No production change, no commitment.

Become a design partner Back to BetterSign