What Security checks
Before credentials are accepted, the SDK hashes the executable that is currently running. The server accepts that measurement only when it matches an active build on the app’s approved-build list. A server challenge and attestation grant are both short-lived and single-use.
Every login creates a new Ed25519 key. The server issues a leaf certificate for that public key, signed by the Vaultix Safety root. The JWT, leaf certificate, client build, and server-side session record are bound together.
Safe rollout
- 1
Build the final executable
Build the final production executable. Any later binary modification changes its hash.
- 2
Approve the build
Open your app’s Security page and upload that executable, or enter the SHA-256 value produced by your trusted release pipeline.
- 3
Set the client version
Set a descriptive version with SetSafetyClientVersion("2.4.1") before login.
- 4
Start in monitoring mode
Enable Monitoring and review integrity events while customers update.
- 5
Switch to enforce
After active customers use approved builds, switch to Enforce.
Return to the app
Why a recorded hash is not enough
Login attestation
The signed measurement contains the app, random server nonce, one-use challenge ID, build hash, version, protocol, and new public key. Replacing any field breaks the signature.
Every API request
The SDK signs the HTTP method, complete path/query, body hash, JWT ID, timestamp, and a new nonce. The server rejects stale timestamps and repeated nonces.
Randomized integrity heartbeat
After login, the server chooses the heartbeat deadline with randomized jitter around the configured interval. When protected traffic arrives after that deadline, the server requires a heartbeat before processing the original request. The SDK obtains a 45-second, one-use challenge, re-hashes the running executable, signs the measurement, submits it, and retries the original request exactly once.
The signed heartbeat binds the protocol, challenge ID, random server nonce, app ID, JWT ID, freshly calculated executable hash, and the public key certified for that session. A captured heartbeat cannot be used for a later challenge or another session. The next randomized deadline is stored by the server, so disabling a client-side timer does not make overdue API traffic pass.
Normal SDK API calls handle required heartbeats automatically. For an otherwise-idle long-running client, call SendSafetyHeartbeat() whenever convenient; the server remains authoritative about whether a heartbeat or key rotation is due.
Certificate chain
The SDK validates the self-signed Safety root, the root signature on the session leaf, certificate validity, and that the leaf contains the exact ephemeral public key generated for this login. It sends both certificates on protected requests; the server validates them again and compares the leaf fingerprint with the stored session.
Production servers must configure persistent SAFETY_ROOT_PRIVATE_KEY_FILE and SAFETY_ROOT_CERTIFICATE_FILE secrets (inline PEM variables are also supported). The dashboard shows a red Development CA badge when they are missing.
Monitoring, enforcement, and revocation
| Mode | Behavior |
|---|
| Disabled | Keeps existing clients compatible. |
| Monitoring | Records unknown hashes but permits login. |
| Enforce | Rejects missing, expired, replayed, revoked, or unapproved attestations. |
- Revoking a build immediately revokes server-tracked sessions using it.
- The SDK automatically answers randomized, server-enforced executable-hash heartbeats during protected API traffic.
- The session key and certificate are rotated less frequently through a separate fresh attestation.
Software-only limitation
Safety does not use TPM or hardware remote attestation. It protects authentication against network replay, stale-build access, ordinary file modification, recorded heartbeats, and use of a stolen JWT without the session key. A skilled attacker with full control of the process can still patch the self-check, report a copied approved hash, or invoke an unmodified client as an oracle. No software-only self-hash can eliminate that limitation.
Responsibility boundary
Vaultix authenticates the submitted client evidence and enforces session, challenge, hash, certificate, and replay rules. Customers remain responsible for securing and hardening their own client application, device runtime, release pipeline, and embedded integration code.
Recommended hardening
- Use TLS verification and certificate pinning
- Protect the release pipeline
- Keep the app API key out of logs
- Revoke compromised builds quickly
- Monitor rejected proofs