Security

General

Trinsic is SOC2 Type I certified and is achieving its Type II certification. All data in transit is encrypted using TLS 1.2 or higher. Data is encrypted at rest using Microsoft Azure managed keys, and the results of verifications are encrypted at the application level using logical, application encryption keys. Our whole platform runs on read only file systems.

Data redaction

Personal data on verification sessions is available, encrypted with an application-level encryption key, through our Dashboard and API. To minimize the time this is available, a redaction period may be configured (which defaults to 30 days if not specified). As a relying party, you can further minimize this by calling the Redact Session API endpoint immediately upon consumption of identity data. This means that the time the data is available on Trinsic's infrastructure could be reduced to milliseconds after a user returns to your application.

Resource access key

To access session results (identity data) via the API, a resource access key is required. Such keys are provided through the local callback of a session (e.g. a redirect or native browser communication), and are not stored or logged by Trinsic.

The identity data for a session may contain additional resource access keys for attachments (such as images of an identity document), which must be exchanged for the underlying attachment data.

Passkeys and encryption

After verifying themselves with a supported provider, a user may be asked to be remembered and added to the Trinsic Network. If they accept, they will be prompted to create a passkey, within which we store encryption key derivation material. We then locally (on the user's device) derive an encryption key and use it to encrypt the user's identity data. No key material is ever sent to our backend.

Upon return, we prompt the user to present the passkey, and locally re-derive the encryption key to decrypt their identity data. While this data is stored on our platform, it is not possible for anyone at Trinsic to decrypt it without the user's consent and direct involvement.

Encryption standards

For application level encryption, we use AES-256-CBC with HMAC-SHA256 for integrity.

Passkey-based encryption of user data uses ChaCha20-Poly1305.

Backup and disaster recovery

Trinsic's data infrastructure on Microsoft Azure is backed up continuously, allowing detailed recovery timelines in case of outages. We yearly test this database recovery to ensure we're able to actually use this.

Access control and least privilege

All administrative access goes through Azure's built-in MFA requirements and is based on the principle of least privilege, with only senior engineering leadership having access to production infrastructure. Within our Dashboard we verify a user's email when using email/password verification and allow you to setup MFA requirements as part of the OIDC login procedures on your company's directory.

Logging, Monitoring and Security

Application-level logs are stored in Datadog for 30 days. Azure security logs are retained for 30 days in the Azure portal. We have continuous monitoring of our infrastructure and code repositories through Datadog's security offerings.

Secure Software Development Life Cycle (SDLC)

We follow best practices in security engineering -- all code is peer reviewed by at least 1 other senior engineer and we have a yearly penetration test against our infrastructure. Our dependencies are updated weekly to ensure we're on the latest vulnerability fixes, including our base container images that run our infrastructure.