Launch on 01/01/2027Licenses available from 01/01/2027
The product

The MFA layer you
run yourself.

A sovereign, embeddable multi-factor authentication and action-authorization layer. You host it, you hold the keys, and it never sees a byte of your users’ personal data — integrated into the products you already run, in a day.

Why it’s different

A better way to do MFA.

The same job — proving it is really your user, and what they approve — built on the right pillars.

YdentifiThe industry default
Your users’ dataNever stored — opaque tokens; you stay the controller.User records and persistent push tokens kept in the vendor’s cloud.
Where it runsYour own infrastructure — any cloud, on-prem, or fully air-gapped.The vendor’s SaaS; you depend on their uptime and region.
Phones home to the vendorNever — no renewal call, no heartbeat, no telemetry. The running deployment has no code path to Ydentifi at all.An on-by-default license check-in or telemetry you have to remember to disable.
Metadata to Apple / GoogleNone — no platform push anywhere in the auth path.Every auth event flows through platform push; metadata leaks with it.
What you authenticateAny action — a signed yes or no over the exact request.Mostly just the login.
Phishing resistanceSigned over the exact on-screen details.OTP or tap-to-approve — relay- and fatigue-attackable.
Device capabilityEvery response carries the tier the device reached, so your server can tell a secure-element biometric from a passcode. A 2D-camera face unlock is not a hardware-backed biometric and is not reported as one.A pass is a pass — no signal of whether the biometric was hardware-grade or a look-alike.
Keys & cryptographyNon-exportable, bound to the device, post-quantum hybrid.Shared secrets or server-side keys; classical crypto.
Lock-inSelf-hosted, gRPC, open SDKs — your keys, your exit.Proprietary cloud; migrating out is costly.

A generalization across the common push- and OTP-based MFA model — no specific vendor implied.

Where it sits

Not an IdP — the layer above it.

Ydentifi is not an identity provider or SSO. It is the multi-factor and action-authorization layer you add to the identity stack you already run — your login, your user directory, your sessions all stay yours. What it changes is how an approval reaches the phone: over a stream the device already holds open, with no Apple or Google push anywhere in the path.

Where the line fallsYdentifi takes one part of the problem. Everything on the left stays where it already is.THE COMPANY KEEPSThe login page, and its designUser accounts, and who they arePasswords, and how they are checkedSessions, and how long they lastRoles, permissions, entitlementsThe business rules for every actionWhat happens when a phone is lostEvery piece of personal dataYDENTIFI TAKES OVERBinding a phone to one identityKeys created inside phone hardwareGetting a request to that phoneShowing the action, taking the biometricChecking the signature that returnsDevices: adding, revoking, banningRecords that reveal alterationLimits that absorb abuseTRUST BOUNDARYa requesta signed answerTwo things cross the line, and nothing else.No name, no email address, no phone number — in either direction, at any point.
What the company keeps on its side of the trust boundary, and what Ydentifi holds on the other.
Your backendthe app your users sign in to
Ydentifiself-hosted, on your infrastructure
User’s phonethe authenticator app

The phone holds a single gRPC stream open to your deployment while the app is active — a channel the device opened, not a push socket registered with a platform.

  1. 1
    Your backend→Ydentifi
    Ask for an approval

    Your server calls IssueAuthChallenge — the challenge is bound to the exact action a user is trying to take.

    gRPC · mTLS
  2. 2
    Ydentifi→User’s phone
    Deliver it down the open stream

    The challenge travels over the SubscribeChallenges stream the device is already holding open. Nothing is handed to Apple Push or Firebase — Ydentifi never learns a push token, because there isn’t one.

    no Apple / Google push
  3. 3
    User’s phone→Ydentifi
    Return a signed decision

    The user approves or denies; the device signs the decision over the exact on-screen details with a hardware-bound key and sends it back via SubmitChallengeResponse.

    gRPC · mTLS
  4. 4
    Ydentifi→Your backend
    Hand back the result

    Your server, still waiting on the AwaitChallenge stream, receives the verified yes or no — and auth_strength, the tier the device reached, which can be higher than the one you asked for.

    gRPC · mTLS

One approval, end to end. Nothing crosses Apple Push or Firebase Cloud Messaging — the challenge rides the stream the device already holds open. (An approval can only arrive while that stream is live.)

At a glance
0end-user records stored
1 daylaptop to production
8SDK languages
2strength levels
gRPConly — no HTTP gateway
hybridpost-quantum crypto
What you get

Four things, in the box.

Everything you need to run sovereign MFA yourself — and nothing needs external API calls at all. The docs are AI-ready, so your coding assistant can do most of the integration for you.

A server image

A Docker container and a PostgreSQL database — that is the whole deployment. Run it on a single host, or put an L4 load balancer in front only when you want high availability.

A CLI

One command-line tool — pull and run, like the server — to provision, deploy, operate, and simulate the entire system. The CLI is the product surface.

SDKs in 8 languages

Go, Python, TypeScript, Java, .NET, Rust, Ruby and PHP, published at launch — or call the gRPC API directly. Plus native Swift and Kotlin SDKs to build the ceremony into your own app.

The authenticator app

The one Ydentifi authenticator your users install — on the App Store and Google Play at launch, and no per-customer app to build or ship. It stays a blank shell until a user links it to your deployment by QR.

How it works

The mechanism, end to end.

From a one-time enrollment to every signed approval — and the sovereign topology it all runs on.

The ceremony

One ceremony, four moves.

Every authentication and every approval follows the same shape. No personal data changes hands, and nothing leaves your infrastructure.

Getting a request to a phoneTwo models. The difference is whether a third party is in the exchange.HOW IT IS USUALLY DONEThe serverhas something to askApple or Googlea third party, alwaysThe phonereceives a notificationThat third party learns that this user authenticated, when, and how often.Fails wherever those services are blocked, filtered, or unreachable.HOW IT IS DONE HEREThe phonedials out, and holdsThe serveranswers on that connectionThe phonereceives the requestNobody else is in the exchange. There is no third party to learn anything.Works on any network where the phone can reach the deployment.What it buysNo metadata leaves the deploymentWorks behind a firewall, or with noroute to the public internet at allNo dependency that can throttle or failNothing to configure per platformWhat it costsNo notification lights up a locked phoneThe request is still there when the appis opened, unless it has expired by thenA held connection per active phone
Two ways to get a request to a phone. The difference is whether a third party sits in the exchange.
01 · Enroll

Bind the device

Once per device, a single-use invite ties the user’s device to their opaque identity. No personal data is exchanged.

02 · Challenge

Ask for proof

When your product hits a sensitive action, your server asks Ydentifi for a challenge carrying the exact on-screen details of that action.

03 · Sign

Approve on device

The enrolled device shows those details and signs them with keys that never leave the phone. The user confirms with Face ID or Touch ID, and a location check stands in front where you ask for one.

04 · Verify

Check the signature

Ydentifi checks the signature against the key the device enrolled with and streams your server the outcome. If it is an approval, the action proceeds — the decision stays entirely yours.

Because the device signs over the exact details the user sees, a phisher who relays your request cannot change the amount, the destination, or the action — the signature simply will not match. That is what “phishing-resistant” means here, concretely.

What you run

Sovereign by design.

Three moving parts, all inside infrastructure you control. There is no Ydentifi cloud in the authentication path.

Your infrastructure

Your product

Your app, your users, your sessions and interface — unchanged. The SDK adds the ceremony where you choose.

+ Ydentifi SDK
Your infrastructure

Ydentifi server

One container and a PostgreSQL database, reachable directly — or behind an L4 (TCP-passthrough) load balancer for high availability. It makes no outbound calls on the auth path.

container · db · optional LB
Your user’s device

Authenticator app

Native iOS and Android at launch. Signs each challenge with keys that never leave the phone.

iOS · Android · at launch

Your server talks to Ydentifi over gRPC with mutual TLS. Ydentifi streams signed challenges straight to the enrolled device — no Apple or Google push in the path, nothing for a platform vendor to throttle or observe. Everything sits inside infrastructure you own.

No personal dataNo outbound callsgRPC-onlyEnd-to-end mTLSPost-quantumHardware-bound
Why it’s built this way

Opinions, on purpose.

A few deliberate design choices explain almost everything else about how Ydentifi behaves.

Not a wrapper

Ydentifi is not a thin wrapper around the big-tech incumbents’ identity platforms. It is built from the ground up — richer, more modular, with no requirement or intention for lock-in. Much more akin to a specialist workshop than a hypermarket.

Unopinionated

There is no one-size-fits-all for roles and sessions, so Ydentifi stays unopinionated about them and lets you decide. A nimble microframework that puts you in the driver’s seat.

Fail-closed

Security and integrity take precedence over availability. When something is wrong, the ceremony refuses rather than waving the request through.

Transparent

We favour transparency about what is under the bonnet, so you can make informed choices — down to the exact algorithms and the topology you deploy. It exposes a metrics endpoint and ships a Prometheus + Grafana profile, so what it is doing is visible in your own monitoring.

Host it anywhere — even away from your regulated data.

Because your end users are opaque tokens, a Ydentifi deployment holds no personal data — so it is not bound to the jurisdiction where your GDPR-regulated data must legally reside. Run the authentication layer wherever it is cheapest, fastest, or most convenient; your personal data stays exactly where the law requires it, in systems Ydentifi never touches.

Factors

What a request can demand.

Match the friction to the stakes — and authorize actions, not just logins.

The factors

Two signed levels, three separate dimensions.

Match the friction to the stakes — a glance for a login, a signed and located approval for a wire transfer. The server owns the policy, and an approval below the level the action asked for is refused.

What a customer can demandTwo signed levels, three separate dimensions, chosen per action rather than per user.1Device unlockThe user unlocked the phone — face, fingerprint, or the passcodeConfirms somebody with the phone’s access is present2Biometric onlyA face or fingerprint check, with no fall back to a passcodeConfirms the enrolled person, not somebody who knows the codeTWO SIGNED LEVELS — THE DEVICE STATES WHICH, AND THE SIGNATURE COVERS ITSEPARATE DIMENSIONSLocationwas the phone where it had to beNumber matchingdid the user read the other screenCodesa baseline where no phone isenrolledSET PER ACTION, BY THE CUSTOMER, IN THEIR OWN CODESigning indemandslevel 1Changing an email addressdemandslevel 2Paying a supplierdemandslevel 2 · number · locationThe level the device claims is inside what it signedA phone cannot claim a stronger check than it performed, and the server refuses anything below what the customer asked for.
Two signed levels, three dimensions chosen independently of them, and three worked examples of per-action policy.
Level 1Device unlockThe user unlocked the phone — face, fingerprint, or the device passcode. Confirms somebody with the phone’s access is present.
Level 2Biometric onlyA face or fingerprint check with no fall back to a passcode. A passcode can be disclosed under pressure or read over a shoulder; removing the fallback narrows who can sign to the person the phone was set up with.
SeparateLocation · number matching · codesChosen independently, not stacked on top. Location asks whether the phone was where it had to be; number matching, whether the user was reading the screen where the action started; codes are the baseline for a user with no enrolled phone. A location check says nothing about who held the phone, so it is asked for separately.

TOTP works with a third-party authenticator, but issuing the shared secret through the Ydentifi app sends it over the device’s own connection to your deployment instead of printing it in a scannable code.

TOTP codes screen
TOTP codes
Location-pinned screen
Location-pinned
Action approval screen
Action approval

Not just who — what.

Ydentifi authorizes actions, not just logins — a signed yes or no over a specific thing, with the exact context shown to the user. Add authorization to any important action or workflow:

Money transfersPurchases & ordersAccess to media & contentSubscriptionsLocking & unlocking physical & digital assetsLaunching deployments or critical engineering processesAnything else you care about
Integration

Adopt it your way.

Partial or full, on your own infrastructure, in the language you already ship.

Integration

Two ways in — both stay yours.

Ydentifi is unopinionated about your users, sessions, and interface. Adopt as much or as little as you like; nothing about your existing login has to change.

Partial

A step-up where it matters

Drop a single ceremony in front of your highest-stakes actions — a signed approval before a transfer, a deployment, an unlock — and leave the rest of your login exactly as it is.

Full

Your whole second factor

Make Ydentifi the second factor across your product, from enrollment through every sensitive action, with the tier chosen per action by your own policy.

Let your AI do the integration.

The docs, protocol files and SDK examples are written to be read by machines as well as people. Point your coding assistant at them and it wires up most of the work — enrollment, challenges, verification — for you. You review and ship; you don’t sweat the boilerplate.

Stand it up

Would rather not spend the engineering time? We can deploy it for you — on your infrastructure, priced to the complexity of the deployment. You keep the keys.

The toolkit

One CLI, the apps, eight SDKs.

Everything is a command — the CLI is the product surface. There is no GUI-only operation and no console you have to sign into.

# bring the server and its database up locally
$ ydfi deploy local up

# provision a relying party — opaque user IDs, no PII
$ ydfi admin create-rp

# sign a relying party’s mTLS certificate from its CSR
$ ydfi admin provision-rp-cert
Provision relying parties and users, and install the license
Create the deployment’s certificates and sign relying-party certificates
Deploy on your laptop or any VM
Seed a demo relying party and issue test challenges
Read health, diagnostics and the storage footprint
Embed it — SDKs in your language
// your server asks Ydentifi for a challenge — no PII, just your token
ch, err := client.IssueAuthChallenge(ctx, ydentifi.IssueAuthChallengeRequest{
    OpaqueID:    user.OpaqueID,
    Context:     []byte("Approve €4,200 transfer to ···· 8842"),
    MinStrength: ydentifi.AuthStrengthBiometric,
})
if err != nil {
    // handle error
}
// the enrolled device shows the details and signs them;
// the deployment verifies the signature and streams you the outcome
res, err := client.AwaitChallenge(ctx, ch.ChallengeID)
if err != nil {
    // handle error
}
if res.Status != ydentifi.ChallengeStatusApproved {
    deny() // declined, expired or refused
    return
}
// an approval always meets the level you asked for
grant(res.AuthStrength)
GoPythonTypeScriptJava.NETRustRubyPHP
Security

The security model.

Who secures what — and the specific threats the mechanism answers.

Security model

Who secures what.

Ydentifi is software you run inside your own boundary, so security is shared: we secure the authentication software and protocol; you secure the infrastructure and keys you run it on. The line is deliberate — it is what keeps you in control and keeps your users’ data yours.

Ydentifi securesthe software & the protocol
  • The cryptography and the wire. Mutual-TLS transport, TLS 1.3 with post-quantum-hybrid key exchange, and signed authentication ceremonies.
  • The server’s correctness. Tenant isolation, input validation, anti-abuse and rate-limiting, and fail-closed behaviour, tested adversarially.
  • Data minimization by design. Ydentifi stores no end-user personal data — only opaque identifiers. There is nothing about your users for us to hold, lose, or be compelled to hand over.
You securethe infrastructure you operate
  • Your certificate authority and its keys. You issue, store, and rotate the keys that root trust in your deployment.
  • The host, network, and database the software runs on.
  • Your relying-party integration and the credentials you issue to it.
  • Access to the operator surface — who in your organization can administer the deployment.
  • You are the data controller for your users. Ydentifi is neither controller nor processor of their data.
  • Assurance of your own deployment. Because the topology, infrastructure, and integration are yours, we encourage a thorough penetration test of the deployment in its entirety — across whichever of the many deployment contexts and options you choose.

Ydentifi provides the mechanism; you operate the keys and the infrastructure. Your users’ data stays with you — and so do the keys to your deployment.

Risk matrix

What it defends against.

The threats that keep a CSO up at night, and the concrete mechanism that answers each.

ThreatHow Ydentifi answers it
Phishing & tampering in transitThe device signs over the exact on-screen details. A relayed request with a changed amount, payee or action breaks the signature.
Stolen or leaked backupSigning keys are hardware-bound and non-exportable. There is nothing in a device backup for malware to lift.
Credential reuse & breaches elsewhereThere is no shared secret on the wire and no PII stored. A breach of some other service tells an attacker nothing.
Personal-data breachYdentifi holds no end-user personal data — there is no honeypot to steal, and no jurisdiction it drags you into.
Future quantum computersSignatures and key exchange are hybrid post-quantum — Ed25519/P-256 paired with ML-DSA-65 — from day one.
Vendor lock-inSelf-hosted, gRPC-only, with open client SDKs. Your keys, your data, your infrastructure — portable by design.
Push-vendor throttling & surveillanceChallenges stream directly to the device with no Apple or Google push in the path to throttle or observe.
A weak or tampered devicePlatform attestation proves each phone is genuine, and every approval names the level of check the phone performed. The server owns the policy, so an approval below the level you asked for is refused.
A lost deviceRe-enroll on a new device; the lost device’s key is revoked and can no longer sign.
Further reading

On passwords & devices.

Passwords aren’t the enemy — how we use them is. You may read our view here → And if you’re weighing passkeys: they fix login, we authorize the action past it — On passkeys →

The design in depth: MFA without Apple or Google push → · Transaction signing and dynamic linking → · Post-quantum MFA →

Before any conversation

Evaluate everything before you talk to anyone.

The API reference, the typed error catalogue, the rate-limit numbers, the load-balancer matrix, and the price are all public — and a local deployment runs in an afternoon. There is no demo to request between you and a verdict. See exactly what you can check →

Opens on 01/01/2027

Available at launch

Until then, you can try the whole ceremony on your own phone.