Launch on 01/01/2027Licenses available from 01/01/2027
Docs / Concepts / Security model

Security model

Ready
TL;DR

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

Who this is for: security reviewers, CSOs, and operators assessing what Ydentifi guarantees, what remains yours, and which threats the mechanism answers. For the deployment details behind the boundary, see Architecture & topology.

Who secures what#

Because you run Ydentifi inside your own boundary, no single party owns the whole picture. The split is clean and deliberate.

Who runs whatFour parties. Only one of them is Ydentifi, and it is above the line.Ydentifiowns the software, issues licensesIssues a signed license file each time the customer downloads one.It is never contacted during a login or an approval.a signed file, replaced each yearTHE DEPLOYMENT— two things to run, installed by the deploying companyThe Ydentifi serverone program — three portsfor theapplicationfor phonesfor the operator(optional)PostgreSQLthe only other thing requiredCertificates and keys are files the operator generates and holds — not a service to run.The relying party’s applicationtheir backend, their user accounts, their dataThe end user’s phonekeys created inside the security chiprequests, and signed answersrequests, and signed answersNothing Ydentifi operates sits below the dashed line.Everything under it belongs to somebody else.
Who runs what: Ydentifi above the line, and below it the deployment, the relying party and the phone.
Ydentifi secures — the software & 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 a fail-closed posture verified by comprehensive adversarial testing.
  • No invented primitives. Every factor rests on a platform or standard mechanism — the device’s own biometric check in its secure element, RFC 6238 codes, ECDSA-P256 and ML-DSA-65 signatures, the platform’s location services. Nothing is judged by a detector we wrote ourselves, because a home-grown one is exactly the part an attacker gets to study and we alone would have to defend.
  • 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 secure — the 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.
  • Assurance of your own deployment. Because the topology and integration are yours, we encourage a thorough penetration test of the deployment in its entirety.
ⓘ In a nutshell

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.

The threat model#

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

Why a valid certificate is not enoughThree questions asked of every caller. The first two are the ones a stolen key defeats.Suppose an attacker steals the deployment’s root signing keyThey can now mint a certificate for any relying party they choose, signed by an authority the server trusts completely.1Does the certificate chain to an authority this port trusts?Yes. They signed it with the stolen root.passeschecked during the handshake2Is its identity in the namespace this port expects?Yes. They wrote whatever identity they wanted.passeschecked during the handshake3Does its fingerprint match the one recorded for that relying party?No. The recorded fingerprint is the real certificate’s.refusedchecked in the application layer, against the databaseStealing the root key is not enough on its ownTo impersonate an existing relying party the attacker must also replace the recorded fingerprint: bywriting to the deployment’s database, or through the operator port, which the same key can mint acertificate for. Keep that port off the network; it binds to localhost by default.
Three checks applied to a caller — and why a stolen root key passes the first two and fails the third.
Phishing & real-time relay

The device signs over the exact on-screen details. A relayed or altered request — a changed amount or destination — breaks the signature.

Stolen or leaked device backup

Signing keys are hardware-bound and non-exportable. There is nothing in a device backup for malware to lift.

Credential reuse & breaches elsewhere

The phishing-resistant factors carry no shared secret on the wire, and no PII is stored. A breach of some other service tells an attacker nothing.

Personal-data breach

Ydentifi holds no end-user personal data — there is no honeypot to steal, and no jurisdiction it drags you into.

A weak or tampered device

Platform 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.

Push-vendor throttling & surveillance

Challenges stream directly to the device with no Apple or Google push in the path to throttle or observe.

Future quantum computers

Signatures and key exchange are hybrid post-quantum — Ed25519/P-256 paired with ML-DSA-65 — from day one.

A lost device

Re-enroll on a new device; the lost device’s key is revoked and can no longer sign. Its TOTP codes stay valid until you replace the secret.

Vendor lock-in

Self-hosted, gRPC-only, with open client SDKs. Your keys, your data, your infrastructure — portable by design.

Data-protection posture#

Ydentifi is neither controller nor processor of your users’ data: it never receives it. You are the data controller for your users. Because nothing in the authentication path carries a name, email, or number, there is no regulated personal data inside the deployment to govern, breach, or subpoena. This is what lets you host anywhere while keeping your personal data where the law requires — and what closes the usual data-protection exposure rather than merely mitigating it. See Opaque identities.

Cryptography#

Two algorithms, everywhere it is possibleAnd an accurate account of the one place it is not.Every signature is made twice, with two unrelated algorithms, and both must verifyA classical-only scheme becomes forgeable the day its algorithm falls. A post-quantum-only scheme restson a younger field with less cryptanalysis behind it. Requiring both means an attacker must break both.WHERE IT APPLIESRoot of trustEd25519 + ML-DSA-65operator custody, offlineIntermediateEd25519 + ML-DSA-65in a key service, non-exportableLicensesEd25519 + ML-DSA-65signed by the intermediateTransport key agreementX25519 + ML-KEM-768where both ends support itThe phone’s own keyECDSA-P256 + ML-DSA-65designed; the shipping app is classicalThe phone forces a compromise, and here is exactly how far it goesNo phone security chip implements a post-quantum algorithm. So on the device the classical half lives inthe chip and the post-quantum half lives in software, protected by the same biometric policy.An attacker with a quantum computermust still break the post-quantum halfAn attacker who fully compromises the phonegets the software half, not the chip’sForging a signaturerequires being both attackers at once
Why every signature uses two algorithms, which layers apply it, and how far a compromise of either one reaches.
  • Hybrid post-quantum, from day one. The mTLS transport uses a post-quantum-hybrid key exchange, licenses are hybrid-signed (Ed25519 paired with ML-DSA-65), and a device can commit at enrollment to hybrid ES256 + ML-DSA-65 approval signatures. Safe against a “harvest now, decrypt later” adversary without waiting for a migration.
  • Hardware-bound keys. Signing keys are generated in the device’s secure element and are non-exportable. Only public keys are ever registered.
  • Signed ceremonies. Every approval is an ECDSA-P256 signature over a canonical payload that binds the exact action — and a hybrid ES256 + ML-DSA-65 signature on devices that commit to post-quantum signing at enrollment. There is nothing to replay and nothing to swap.
  • History in a log stream you keep. Device-lifecycle events — enrollment, replacement, revocation, ban — and what the server did are both emitted as structured lines to your own log pipeline, so their retention and access are whatever that pipeline already does. The database stores neither, and the product offers no export format of its own. Neither carries any integrity value: they cannot tell you whether someone with write access to your log store has edited them. Protecting that is your side of the line, and the product does not claim otherwise.

Fail-closed by default#

When something is wrong — an expired certificate, an ambiguous state, a strength that cannot be met — the ceremony refuses rather than waving the request through. Security and integrity take precedence over availability, everywhere the two conflict.

Relates to
← Previous
Factors & levels
Next →
Quickstart
Architecture & topologyOpaque identitiesRotate mTLS certsErrors
Opens on 01/01/2027

Available at launch

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

Try the live demo