Is data encrypted in transit?

Yes. TLS terminates every connection at the public edge, with HSTS and security headers, and the primary ledger database refuses plaintext connections outright.

Are ID images encrypted at rest?

Yes, with AES-256-GCM, for the time they exist before the automatic retention purge deletes them.

Is everything in the database encrypted at rest?

No, not today. ID images and dates of birth are encrypted; we do not claim disk- or database-level encryption for every table and volume, and we won't imply otherwise.

Where are API keys and secrets stored?

In a dedicated secrets vault, accessed only over a token-gated API. API keys themselves are stored as SHA-256 hashes, with only a short prefix kept in clear.

Are backups encrypted?

Yes, with AES-256, encrypted before they leave memory using a key held in the secrets vault. The backup script refuses to write an unencrypted file if that key is unavailable.

Do you have DDoS protection or a web application firewall?

No, not today. Basic rate limiting protects sign-in and other high-cost endpoints, but there is no CDN or WAF in front of the origin yet.

Encryption

Where encryption is used, and where it isn't yet.

Encryption protects a verification at several distinct points: the connection, the image, the secret, the backup, the password. We'd rather list each one honestly than say "encrypted" once and let you assume it covers everything.

What's encrypted at rest Trust overview

In transit

TLS at the edge, and enforced on the ledger database.

Every request to ShieldID is encrypted before it reaches the application.

The public edge terminates TLS for every connection, with HSTS and a locked-down set of security headers, so a request is encrypted before it reaches anything behind it.
The primary ledger database enforces TLS on every connection it accepts. A plaintext connection is refused outright, not merely discouraged by configuration.
The application verifies the database's certificate against a pinned authority and checks its hostname, rather than trusting whatever certificate shows up first.

At rest

ID images and dates of birth are encrypted. We're specific about what else isn't, yet.

"Encrypted at rest" is often said about an entire platform in one breath. Here is what that actually covers today.

ID images and the selfie: Encrypted with AES-256-GCM while stored, ahead of the automatic purge that deletes them.
Date of birth: Stored encrypted, never in plain text, wherever a verification record holds it.
Secrets (API keys, database credentials, signing keys): Held in a dedicated secrets vault, not in application config or source.
The rest of the database and general storage volumes: Not encrypted at the disk or database level today. We say so directly rather than implying blanket coverage.

Secrets

One vault, token-gated, with rotation on the record.

Application credentials don't live scattered across config files.

Centralized

API keys, database credentials and webhook secrets are held in a dedicated secrets-management system, read and written only over an authenticated, token-gated API.

Rotation is audited

A dedicated rotation process records every credential change and every refused attempt in a tamper-evident log that stores only fingerprints of the values, never the values themselves.

Never in code or config

Secrets are read from the vault at boot, not committed to source or left in an environment file that ships with a deploy.

Backups

Encrypted before they leave memory, with a restore drill you can run without touching production.

A backup covers the application, its configuration and the database.

Encrypted with AES-256, using a key held in the secrets vault. If that key isn't available, the backup script refuses to write an unencrypted file rather than falling back silently.
A documented, scripted restore procedure exists and supports a rehearsal mode into a scratch location, so the process can be tested without touching live data.
Backups stay on the same premises today. We do not offer geo-redundant backups or a separate disaster-recovery site, and we say so on the residency and compliance pages rather than only here.

Passwords, sessions and API keys

Nothing that authenticates you is stored in a form someone could read and reuse.

Three different kinds of secret, three different treatments, all one-way.

Passwords: Hashed, never stored or logged in plain text.
Session tokens: The token in your browser's session cookie is a random 32-byte value set as an HttpOnly cookie.
API keys: Stored as SHA-256 hashes. Only a short prefix is kept in clear, so you can recognise a key in a list without the full value ever being retrievable again.

What this page does not claim

No DDoS protection, no WAF, no geo-redundancy.

We don't sit behind a content-delivery network or a web application firewall today, and we don't claim disk- or database-level encryption for every byte we store. Basic rate limiting protects sign-in and other costly endpoints, but it isn't a hardened, persistent abuse-protection layer yet. If a specific control matters for your organization's own review, ask us directly rather than assuming a general phrase covers it.

Questions

Straight answers about encryption.

Read how retention and residency fit together.

Encryption is one control among several. See what's purged, when, and where the data sits while it exists.

See retention & deletion Read the trust overview