Seventh Sense
Trust centerTHE EVIDENCE / OPEN TO SCRUTINY

Trust starts with a person.

See what we store, what we never store, and how we answer seven questions every biometric vendor should face. Review the evidence before you talk to us.
00Data accounting

See the evidence.

Never stored
  • Biometric images — not retained by the documented face-token provisioning and phone sign-in flows
  • Face images and templates — not retained in the documented IdP phone flow
  • PKI private keys — generated in memory only for face sign or face decapsulate; never stored
Stored
  • An encrypted, revocable SensePrint per enrollment — designed to be unlinkable and engineered to be irreversible
  • PKI public keys go directly to relying parties; certificates have separate retention requirements. IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and verifier challenges, standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys.

"Designed to be" and "engineered to be" are deliberate: these are properties of our construction, stated as such.

Revoke and reissue a SensePrint through the registry. Credential revocation does not delete personal data, and offline verifiers need updates to learn about revocation. The architecture whitepaper documents the full lifecycle.

01Seven questions for any biometric vendor

Seven questions to ask any biometric vendor.

01Is a biometric template ever stored?

IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Administrator photo provisioning processes the image transiently; the licensed on-premises webcam method processes live captures inside the customer deployment.

02Does a plaintext private key ever exist at rest?

A live biometric generates post-quantum PKI key-pairs in memory. Store the public keys; the private keys exist only during face sign or face decapsulate operations and are never stored. IdP retains encrypted tenant signing keys and uses classical ES256 for OIDC federation. Device and infrastructure keys have their own custody rules. Public keys, signatures and decapsulated shared secrets go directly to relying party endpoints, without the IdP seeing them.

03Is the cryptography post-quantum by design?

SenseCrypt PKI generates post-quantum ML-DSA and ML-KEM key-pairs in memory, retains public keys, and never stores the private keys. IdP retains encrypted tenant signing keys and uses classical ES256 for OIDC federation. SenseCrypt IdP supports FAPI 2.0, FAPI 2.0 Message Signing and FAPI-CIBA for financial-grade flows. Protocol support does not itself establish certification or FIPS module validation. Public keys, signatures and decapsulated shared secrets go directly to relying party endpoints, without the IdP seeing them.

04Can credentials be linked across services?

Credentials are designed for default unlinkability across services. Optional consented linkage is a separate configuration, and account or integration metadata can still identify the person.

05Is liveness enforced before key material is created?

For the face-derived key ceremony, our own presentation-attack detection runs at capture before that key is recreated. This does not describe the creation of every device or infrastructure key. We publish no PAD performance numbers.

06Are there public developer docs?

Yes — docs.sensecrypt.com, with Python, REST, and native mobile (Android & iOS) SDKs you can read today.

07Has the recognition been evaluated by NIST under your own name?

Yes — Seventh Sense entered NIST FRVT in 2021 and continued in the evaluation program now divided into FRTE and FATE. This is recognition-algorithm evaluation, not certification of the whole platform.

02Proof inventory

Follow the evidence.

Public docs & SDKs

docs.sensecrypt.com — Python, REST, and native mobile (Android & iOS), readable before you talk to sales.

Liveness checks at capture

Presentation-attack detection applied at capture before a face-derived key is recreated. Liveness tested by iBeta to ISO/IEC 30107-3 Levels 1 and 2, within the tested component and attack conditions; this does not certify every integration or cover all injection attacks.