Deploy decentralised Face ID encryption and authentication without any biometric database, reducing privacy risk and supporting regulatory compliance.
Traditional biometric systems give you strong authentication, but only by collecting and retaining data that can never be reset if it leaks. That trade-off creates three problems every security and compliance team eventually has to answer for.
Biometric databases become high-value breach targets. A leaked face can never be changed, the exposure is permanent.
Sensitive biometric records increase governance obligations under GDPR, BIPA, CCPA and similar frameworks, more to classify, secure, disclose and delete.
People are increasingly uncomfortable with permanent biometric storage, and slower to adopt services that demand it.
Facenition removes all three.
FaceID, Okta, Microsoft, Entrust and traditional biometric platforms all rely on collecting or storing biometric data somewhere. Facenition is the only approach that delivers biometric-grade encryption while holding no biometrics at all.
Verifies identity using face recognition
Stores no biometric or face, ever
User-controlled identity tokens
Revocable, rotatable and expirable
Portable across organisations and vendors
Dramatically reduced privacy exposure
Biometric-grade assurance, with nothing for an attacker to steal.
Facenition fits into your existing identity flow and feels familiar to your users, while removing the liability you'd normally carry. Four steps, no biometric database.
The user creates a privacy-preserving identity token from a face snapshot. The biometric itself is never stored.
Your organisation keeps a revocable identity token instead of biometrics. There's no biometric database to secure, govern or worry about.
On return, a live reading regenerates the token on the user's device and matches it against the one on file, fast, strong authentication with no stored biometrics.
Tokens can be rotated, expired or revoked instantly, something a leaked biometric can never be.
Wherever an organisation needs to confirm who someone is, and would rather not hold their biometrics to do it, Facenition fits cleanly into the flow.
Citizen identity and digital services, verify people with confidence while collecting far less sensitive data to secure and answer for.
Accurate patient verification without ever building a biometric database of the people you care for.
Customer onboarding and fraud prevention with strong identity assurance and far less privacy risk on your balance sheet.
Physical and digital access control without enrolling employees into a biometric record you then have to protect.
Other applications include SaaS platforms, digital identity ecosystems, compliance and audit workflows, and cross-organisation verification.
Passwords are weak and resettable. Traditional biometric systems are strong but store data that can never be reset. Here's how Facenition compares on the criteria buyers use to justify the decision internally.
| Passwords | Traditional biometric systems | Facenition | |
|---|---|---|---|
| Stores biometric data | n/a | Yes, indefinitely | Never |
| Breach liability | Resettable | Permanent & irreversible | Nothing to expose |
| Right to deletion | Straightforward | Complex, biometrics persist | No biometric to delete |
| Biometric lifecycle management | n/a | Required & ongoing | None needed |
| Compliance burden | Moderate | Heavy | Minimised |
| Cross-platform portability | — | — | ✓ |
| User ownership of identity | — | — | ✓ |
| Revocation capability | Reset | — | ✓ |
| Vendor independence | Partial | — | ✓ |
| Privacy-first design | — | — | ✓ |
Most identity systems put the platform, or the government, in charge of who you are. Facenition flips that. Because identity tokens are generated on demand and never tied to a stored biometric, the person decides how their identity is created, separated, shared and switched off. This is the difference between being verified and being owned.
People can generate as many identity tokens as they need, one per service, or one per purpose, all from the same person, none linkable back to a biometric.
Keep identities for different organisations cleanly separated, so a token used with one vendor reveals nothing about activity with another.
Set tokens to expire after a defined period, so access naturally winds down instead of lingering indefinitely.
Revoke a token instantly, anywhere it's been issued, cutting off access without re-enrolment or touching a biometric.
Identity isn't trapped inside one provider. Tokens work across vendors and systems, so users are never locked in.
The person, not the platform, decides what their identity is used for. Privacy becomes a default, not a setting buried in a policy.
Facenition is designed to slot into the systems you already run, so you can add privacy-first verification without rebuilding your identity stack.
Connecting a system we don't list yet? Integrations can be built to fit your environment, talk to our team.
Start building in minutes and scale from a single project to a fully on-premises deployment. Every tier keeps biometrics off your servers, Facenition stores identity tokens, never faces.
For developers and agencies who want to experience Facenition and integrate it into client projects.
For app and business owners who want to improve the privacy and security of their customers.
A license to operate a Facenition API server on your own infrastructure, full control, no per-call limits.
Need something in between? On-premises and high-volume plans can be tailored, just reach out.
Deploy Biometric encryption without maintaining a biometric database. See it working, or talk to our team about where Facenition fits in your organisation.
Facenition transforms identity into a secure digital credential by combining decentralised biometric verification, personal knowledge, purpose-based access controls, and configurable expiry. The result is a privacy-first foundation for signing documents, sharing records, exchanging contracts, and establishing trusted digital relationships.
Digitally sign and verify documents with end-to-end privacy and independent verification.
Why it mattersEvery signature is tied to both the signer and the intended recipient, ensuring documents can only be verified by authorised parties. This creates strong proof of authorship while preserving privacy and control.
Authenticate, protect and verify wills and estate documents throughout their lifecycle.
Why it mattersProvide lasting assurance that a will was created and approved by the correct person, with independent verification available to authorised legal representatives when required.
Passwordless two-factor authentication without reliance on central identity providers.
Why it mattersGive users fast, password-free access while reducing account takeover risk. Each login is verified directly by the user without dependence on central identity providers.
User-controlled identity and login credentials that remain under individual ownership.
Why it mattersCreate a reusable digital identity that remains under the user's control. Organisations can verify identity when needed without collecting or storing unnecessary personal information.
Encrypt, store and manage sensitive documents with user-controlled access rights.
Why it mattersProtect sensitive files with user-controlled access and sharing permissions. Grant, limit or revoke access at any time while maintaining complete visibility over who can open each document.
Privacy-compliant sharing of healthcare records between patients and authorised providers.
Why it mattersEnable patients to share healthcare information with confidence. Access is granted only to authorised providers for approved purposes, helping organisations meet privacy and compliance obligations.
Secure transfer and controlled sharing of files between individuals and organisations.
Why it mattersTransfer files securely between individuals, teams and organisations. Access can be restricted to specific recipients and automatically limited by time or purpose.
Exchange, verify and manage agreements between parties with an immutable audit trail.
Why it mattersExchange agreements with confidence, knowing every action is attributable to the correct party. Built-in verification and auditability help streamline approval and compliance processes.
Establish trusted digital relationships and identity handshakes between users, organisations and systems.
Why it mattersEstablish trusted digital relationships between people, organisations and systems. Mutual verification creates confidence in every interaction without requiring a central intermediary.
Every solution runs on the same API and the same live demo. Start with the interactive demo, then wire it into your stack when you're ready.
A conceptual overview of how Facenition combines face biometrics with strong cryptography to authenticate people and protect data, without building a biometric database. Written for security, privacy and product leaders.
Facenition is a privacy-first decentralised identity platform that lets organisations verify a person by their face and protect data on that basis, without storing faces or operating a biometric database. A live face is processed in the moment and combined with secrets the user controls to produce a compact, revocable identity token. That token, not the face, is what an organisation keeps.
The problem it solves. Authentication today still leans on passwords and shared secrets that are routinely phished, reused and stolen, while the biometric systems meant to replace them create permanent databases of data that can never be reset if leaked. Organisations are forced to choose between weak credentials and heavy biometric liability.
Why biometrics and encryption belong together. A face proves who is present; cryptography proves integrity and confidentiality. Used alone, a biometric is a liability to store and a password is trivial to steal. Bound together, a live face cryptographically tied to keys and tokens, you get authentication that is both hard to forge and safe to hold, because what persists is protected, scoped and reversible.
Faces are processed transiently and discarded. Only non-reversible tokens are stored.
Tokens depend on inputs the user holds, so identity is not centrally owned.
A token works only in the context it was made for and can be re-issued at will.
Standard, well-understood cryptographic primitives bind identity to data protection.
Digital identity is still anchored to secrets, passwords, one-time codes, knowledge questions, that are easy to lose and easy to steal. The result is a threat landscape where the front door, not the firewall, is the weakest point.
The market has responded with more factors and more friction, but the underlying issue is unchanged: secrets can be copied, and the data we collect to verify people often becomes the next thing worth stealing. A durable answer has to verify the person while holding less, not more, sensitive data.
Figures above reflect directional trends consistently reported across public industry research; they are indicative rather than a single cited source.
Facenition is built on a small set of principles that shape every design decision. They position the platform around outcomes, privacy, control, assurance, rather than any particular mechanism.
The most private system is one that never collects what it doesn't need. Faces are processed, not stored.
People should hold the keys to their own identity. Verification depends on inputs the user controls.
Identity and data protection rest on standard, peer-reviewed cryptographic practice, no security through obscurity.
Data minimisation and clear consent are first-class, making privacy obligations easier to meet.
Every verification is evaluated on its own merits; no implicit trust is granted by network or prior state.
Facenition augments existing identity stacks rather than replacing them, via a simple, standards-friendly API.
At a conceptual level, Facenition turns a live face into protected access through a short, one-directional pipeline. Each stage hands a safer artifact to the next, and the original biometric never leaves the moment of capture.
A user presents a live face once. Facenition combines it with the user-controlled inputs and scope to produce an identity token, which the relying application stores against the account. The face is discarded.
When the user returns, a fresh live capture is processed with the same inputs and compared to the stored token. A genuine match confirms the same person is present; the system tolerates the natural variation between captures while rejecting different people.
A successful verification becomes an authentication signal your systems can act on, issuing a session, satisfying a second factor, or unlocking a protected resource. Facenition returns a simple decision (and optionally a confidence score) that slots into existing logic.
Because tokens are revocable, recovery is straightforward: a user re-enrolls to produce a fresh, unrelated token, and the old one is retired. There is no permanent biometric secret to reset, the reset that traditional biometrics never had.
For most stakeholders, privacy, not cryptographic detail, is the deciding factor. Facenition's architecture is designed so that the privacy story is simple to state and easy to defend.
Facenition does not retain raw faces or build a central gallery of users. Captures are processed transiently and discarded. What persists is a token that contains no image and no reusable biometric.
The compact representation derived from a face is protected before it ever becomes a stored artifact, and is bound to user-controlled inputs. A stored token is non-reversible: it cannot be turned back into a face, and on its own reveals nothing about a person's appearance.
Any biometric-derived material is protected in transit and, where retained, at rest using standard encryption. Identity-bound keys can be used to encrypt the data a verification unlocks, so confidentiality follows the verified identity.
The platform collects the minimum needed to perform a verification and keeps the minimum needed afterward, typically just a token. Less data held means less to govern, secure and disclose.
Enrollment is an explicit, user-initiated act. Because tokens are scoped and user-controlled, consent maps cleanly to purpose: a user can enroll for one context without that decision extending to another.
Tokens have a clear lifecycle, created at enrollment, used at verification, expired or revoked on demand, and replaced by re-enrollment. Deletion is meaningful because there is no shadow biometric copy to leave behind.
Facenition is designed against a practical threat model. The table below maps common threats to the protections the architecture provides. Specifics such as thresholds, matching logic and anti-spoofing techniques are deliberately omitted.
| Threat | How Facenition mitigates it |
|---|---|
| Database breach | No biometric is stored; tokens are non-reversible and scoped, so a stolen store yields nothing that can be replayed or turned back into a face. |
| Replay attacks | Verification requires a fresh, live capture each time; a captured static artifact does not satisfy a live check. |
| Stolen devices | A token alone cannot impersonate a user, verification still requires a live face and the matching user-controlled inputs, and can be combined with additional factors. |
| Insider threats | Least-privilege access controls and scoped tokens limit what any single actor can obtain or reuse; there is no central biometric trove to abuse. |
| Credential theft | Face verification reduces reliance on shared secrets that can be phished, reused or dumped, removing the attacker's favourite entry point. |
| Synthetic / duplicate identity | Quality and liveness screening, plus same-person consistency checks, raise the bar against fabricated or recycled identities at onboarding. |
The model assumes a capable adversary with access to leaked data and stolen devices, and is built so that compromising any single artifact, a token, a device, a database, does not by itself grant access. Defence-in-depth, not a single secret, is the goal.
Facenition relies on well-established, industry-standard cryptography rather than novel or unpublished primitives. The security of the platform rests on the strength of these standards and on sound key management, not on secrecy of the algorithms.
By holding far less sensitive data, organisations using Facenition can reduce the scope and burden of their compliance programmes. Facenition is designed to align with the requirements below; alignment describes design intent and supports an organisation's own compliance, and is distinct from formal certification.
| Framework | How Facenition helps |
|---|---|
| GDPR | Supports data minimisation and privacy-by-design, simpler lawful-basis and consent handling, and easier data-subject requests because there is no stored biometric to disclose or erase. |
| SOC 2 | Architecture aligns with the security, availability and confidentiality trust-service criteria; reduced data holdings simplify controls and evidence. |
| ISO 27001 | Fits an information-security management system through clear data classification, minimisation and lifecycle controls. |
| Regional privacy laws | Helps address CCPA/CPRA, BIPA and similar biometric-privacy regimes by avoiding the collection and retention of identifiable biometric records. |
Governance is strengthened by the same property that drives the privacy story: when the most sensitive data is never collected, retention, access and breach-notification obligations all shrink. This document describes alignment and design intent; specific certifications are pursued as part of the roadmap and stated explicitly only once achieved.
Facenition fits anywhere an organisation needs to prove a real person is present, and it does so while reducing, not increasing, the sensitive data held.
Passwordless, phishing-resistant sign-in for web and internal applications, replacing or strengthening passwords with a live face check.
Strong second-factor or step-up verification for employees and contractors, and face-gated entry for physical access points.
High-assurance verification for account access, payment approval and high-risk actions, with a confidence score for risk-tiering.
Verify clinicians and patients at the point of care without building a biometric record of a sensitive population.
Match a live selfie to a document portrait during KYC, with quality and liveness screening to cut failed and fraudulent sign-ups.
Bind decryption of sensitive files or records to a live, verified face so confidentiality follows identity.
Facenition's direction is to broaden reach and deepen enterprise fit while holding the privacy-first line. The roadmap below is indicative and high-level.
Wider availability, additional language and SDK coverage, and expanded deployment options including on-premises.
First-class mobile capture and on-device support to bring face verification natively into apps.
Complementary factors and step-up options that combine cleanly with face verification for higher-assurance flows.
Turn-key connectors for major identity providers and enterprise directories, plus richer policy controls.
Pursuit of formal third-party attestations to complement the platform's privacy-by-design foundation.
This whitepaper is a public overview intended for evaluation. It describes Facenition's properties, principles and intended compliance alignment at a conceptual level and deliberately omits proprietary implementation details. It is not legal advice; compliance outcomes depend on how the platform is deployed and operated.
Everything you need to integrate privacy-first decentralised face verification: the REST API reference, identity-provider integration guides, and reference architectures for the most common scenarios.
All requests are POST. The base URL is https://api.facenition.com; each endpoint is reached at https://api.facenition.com/<endpoint>.
Every endpoint except /generateToken and /token requires a client token. Send it in the X-Auth-Token request header (it may also be supplied as an auth_token form field). Keep this token on your server, never ship it to a browser or mobile client.
Image fields accept a file upload via multipart/form-data (recommended). To send several images, repeat the same field name once per image. Image fields also accept a base64-encoded string in an application/json body.
Several endpoints take an accuracy parameter, an integer from 1 to 8 (default 4) controlling matching tolerance. For verification, use the same accuracy at /generate and /authenticate.
On failure a response returns { "ok": false, "error": "<message>" } with an HTTP status, 400 bad request, 401 unauthorized, 404 not found, or 502 upstream error.
Facenition is a server-to-server API. In every integration the pattern is the same: your client captures a face, your backend (or your identity provider's hook) forwards it to Facenition with your client token, and Facenition returns a token, a boolean, or a score. The client token never touches the browser.
# 1) Enrolment, create an identity token (store the token, discard the photo)
curl -X POST https://api.facenition.com/generate \
-H "X-Auth-Token: $FACENITION_TOKEN" \
-F "photo=@enroll.jpg" \
-F "password=$USER_SECRET" \
-F "scope=app:login" \
-F "accuracy=4"
# -> { "ok": true, "token": "a1b2...", ... }
# 2) Verification, check a live face against the stored token
curl -X POST https://api.facenition.com/authenticate \
-H "X-Auth-Token: $FACENITION_TOKEN" \
-F "token=$STORED_TOKEN" \
-F "photo=@probe.jpg" \
-F "password=$USER_SECRET" \
-F "scope=app:login" \
-F "accuracy=4"
# -> { "ok": true, "authenticated": true }
Use Okta to handle primary authentication and call Facenition as a custom step-up check during sign-in. The cleanest hook points are an Okta Inline Hook (token or registration) or an Okta Workflow.
/generate from your backend, and write the returned token to a custom Okta profile attribute (e.g. facenitionToken) via the Users API.facenitionToken, takes the live capture your front-end collected, and calls /authenticate. Return a command that allows or denies the transaction.// Okta Inline Hook endpoint (Node/Express, server-side)
app.post("/okta/facenition-hook", async (req, res) => {
const claims = req.body.data.context.user.profile;
const form = new FormData();
form.append("token", claims.facenitionToken);
form.append("photo", req.liveCapture, "probe.jpg"); // collected by your UI
form.append("password", await secretFor(claims.login));
form.append("scope", "okta:login");
form.append("accuracy", "4");
const r = await fetch("https://api.facenition.com/authenticate", {
method: "POST",
headers: { "X-Auth-Token": process.env.FACENITION_TOKEN },
body: form
}).then(x => x.json());
res.json(r.authenticated
? { commands: [{ type: "com.okta.action.update", value: { credential: "VERIFIED" } }] }
: { error: { errorSummary: "Face verification failed" } });
});
Entra ID exposes custom authentication extensions and Conditional Access. Register an HTTPS extension that fires at sign-in, perform the same /authenticate call from that endpoint, and return a continue/block decision. For AWS IAM environments using Amazon Cognito, wire Facenition into the custom-auth Lambda triggers:
# Cognito custom auth flow (IAM)
DefineAuthChallenge -> issue a CUSTOM_CHALLENGE ("present your face")
CreateAuthChallenge -> nothing secret needed; the token lives in your store
VerifyAuthChallenge -> POST the live capture + stored token to
https://api.facenition.com/authenticate
set answerCorrect = response.authenticated
Use a OneLogin Smart Hook (pre-authentication or user-migration). The hook runs your JavaScript on OneLogin's side; have it call your thin verification service (which holds the client token) and resolve { success: true|false } based on the /authenticate result. Store the per-user token in a OneLogin custom user field at enrolment.
If you operate your own IdP, model Facenition as one node in the authentication journey: password → Facenition face check → issue assertion. The IdP collects the capture, your backend calls /authenticate, and the node passes or fails. Because Facenition returns a simple boolean (or a score via /authenticate-score), it slots into existing decision logic with minimal glue.
Facenition sits behind your application as a stateless verification service. Your systems own identities, sessions and the token store; Facenition turns a face into a token or a yes/no. Nothing about a user's appearance is persisted by either side.
/generate), verification (/authenticate, /authenticate-score), matching (/match, /match-bulk, /consistency-check) and screening (/quality, /detect, /liveness).Enrol: capture → /generate (scope app:login) → store token on the user. Sign in: capture → /authenticate with the stored token → on true, issue a session.
Run your existing password step first. Then capture a face and call /authenticate as the second factor. Only mint the session when both the password and the face check pass, face becomes a possession-free "something you are" factor.
Enrol each authorised person with /generate and keep their tokens in a roster. At the door, capture once and evaluate against the roster, call /authenticate per enrolled token (or use /match-bulk against reference captures). Grant on the first match; otherwise deny.
Enrol the document portrait with /generate, then verify the live selfie with /authenticate-score to obtain a match decision plus a similarity score and threshold, useful for risk-tiering onboarding decisions. Pre-screen the selfie with /quality and /liveness to cut failed onboardings.
Derive a content key in your client from the user's passphrase bound to their identity token, and encrypt locally (e.g. AES-GCM). To decrypt, require a fresh /authenticate pass before the key is reassembled, the face gates release of the key, and Facenition never sees the file.
Hold one reference per known identity. Given a probe face, call /match-bulk against the set to flag matches, or /consistency-check to confirm a group of images is the same person (e.g. de-duplicating accounts).
scope, expiry and accuracy used to verify must match those used to enrol.Reference designs for the most common decentralised, biometric-backed flows. Every flow is stateless: Facenition turns a face + PIN into a verdict or seals/opens an artifact, and hands it straight back to you. Your application owns sessions, redirects, and storage; Facenition stores nothing about a user except, optionally, their public keys. Pick a card to jump to its full guide.