TTL Secrets

A TTL secret is a temporary, one-shot secret designed for sharing credentials with someone who doesn't have access to your vault. Instead of pasting a database password into Slack or emailing an API key, you create a TTL secret that self-destructs after it's viewed -- or after a failed attempt.

TTL secrets are fundamentally different from regular secrets:

• They have a time-to-live -- they expire and are destroyed after a set duration
• They are one-shot -- a single view attempt destroys them, whether the passphrase is correct or not
• They are accessed by people, not machines -- the recipient opens a link and enters a passphrase
• They cannot be granted to machines -- machines cannot read TTL secrets via the SDK or CLI

How It Works

1. You create a TTL secret from the dashboard within a project
2. SikkerKey encrypts the value and generates a random passphrase
3. You receive a link and a passphrase -- share these with the recipient through separate channels
4. The recipient opens the link, enters the passphrase, and sees the secret
5. The secret is permanently destroyed

One shot, no exceptions. A correct passphrase reveals the secret and destroys it. A wrong passphrase destroys it without revealing anything. Expiry destroys it. There is no second attempt.

Creating a TTL Secret

From the secrets page, click + New Secret and select TTL Secret.

You'll see:

• Name -- a label for your reference (e.g. "Staging DB password for Dave")
• Value -- paste the credential you want to share, or check Generate random secret to have SikkerKey generate one
• Self-destruct after -- two input boxes for hours and minutes. Maximum 24 hours, minimum 1 minute. Recommended: 5 minutes.

If you check Generate random secret, the value input is replaced with configuration for:

• Generated length -- how many characters (1 to 1024)
• Charset -- symbols, alphanumeric, numbers, or uuid

This uses the same generation logic as automatic rotation for regular secrets.

After Creation

The modal transforms to show two pieces of information:

• Link -- the URL the recipient will open (e.g. https://api.sikkerkey.com/vault_abc123/token_here)
• Passphrase -- a 6-word passphrase like anchor-blade-castle-delta-ember-frost

Both have copy buttons. This information is shown once and never again. If you close the modal without copying, the passphrase is gone forever. The secret still exists but becomes unretrievable by you.

Sharing Safely

For maximum security, share the link and passphrase through different channels. For example:

• Send the link via email, send the passphrase via Signal
• Post the link in a Slack thread, share the passphrase in person
• Put the link in a ticket, call the recipient with the passphrase

If an attacker intercepts one channel, they still can't access the secret without the other. And if they try the wrong passphrase, the secret is destroyed -- alerting you via the status change on the dashboard.

The Recipient's Experience

The recipient opens the link in any browser. No account, no login, no app required.

They see a branded SikkerKey page with:

• A warning that this is a one-time secret
• A passphrase input field
• A "View Secret" button

If the passphrase is correct, the secret is displayed with a copy button. The secret is simultaneously destroyed on the server.

If the passphrase is wrong, the secret is destroyed and the recipient sees a "Secret Destroyed" message. There is no retry.

If the secret has already been viewed, destroyed by a failed attempt, or expired, the page shows "Secret Not Available."

Encryption

TTL secrets are encrypted server-side with AES-256-GCM using SikkerKey's data encryption key -- the same encryption layer used for other sensitive data at rest (TOTP secrets, recovery codes). The passphrase is hashed with Argon2id before storage.

The server never stores the plaintext passphrase. On a correct passphrase submission, the server:

1. Verifies the passphrase against the Argon2id hash
2. Decrypts the value
3. Clears the encrypted data and hash from the database
4. Returns the plaintext to the recipient
5. Updates the status to viewed

On a wrong passphrase, step 1 fails and the server clears all data immediately without decrypting.

Status Tracking

TTL secrets appear in a dedicated section at the bottom of the project's secrets page. Each shows a status:

This gives you visibility into whether the handoff succeeded. If a secret shows destroyed, you know either someone tried the wrong passphrase or an attacker intercepted the link and failed. Either way, the credential was never exposed.

Lifecycle Limits

• Minimum TTL: 1 minute
• Maximum TTL: 24 hours
• Recommended TTL: 5 minutes

Shorter is better. A 5-minute window is enough for someone to check their messages, open the link, and enter the passphrase. A 24-hour window is a 24-hour attack surface.

Expired secrets are cleaned up by a background job that runs every 60 seconds.

Machine Access

Machines cannot interact with TTL secrets. They are not stored in the same table as regular secrets, so:

• Machines cannot be granted access to TTL secrets
• The SDK and CLI cannot read TTL secrets
• TTL secrets do not count against your regular secret limits
• TTL secrets do not appear in machine secret listings or exports

This is by design. TTL secrets are for human-to-human credential handoff, not for programmatic access.

Project Scope

TTL secrets belong to a project. If you delete the project, all TTL secrets in that project are deleted immediately -- including any that haven't been viewed yet.

Audit Logging

Three audit events are recorded:

• temporary_secret_create -- when you create a TTL secret
• temporary_secret_viewed -- when the recipient successfully views it
• temporary_secret_failed -- when someone enters the wrong passphrase

All events include the source IP address of the request.

When to Use TTL Secrets

Use TTL secrets for:

• Sharing database credentials with a new team member
• Sending an API key to a contractor
• Passing a one-time setup token to a colleague
• Any situation where you'd otherwise paste a credential into chat

Don't use TTL secrets for:

• Secrets that machines need to read -- use regular Secrets or Structured Secrets
• Credentials that need to persist -- TTL secrets are destroyed after one view
• Sharing with multiple people -- each TTL secret can only be viewed once by one person