Temporary machines

What are temporary machines?

Temporary machines are SikkerKey machine identities with a fixed end date and optional per-machine guardrails. They are built for bounded engagements: contractor access, penetration tests, incident response, migrations, demos, time-limited audits, and other workloads that should not become permanent infrastructure.

A temporary machine has its own expiration time. It can also carry a purpose note, extension history, and guardrail settings for where and when it is allowed to read secrets.

How they are created

Temporary machines are created from a single-use temp bootstrap token. The vault owner creates the token from the dashboard and chooses:

• Machine name
• Optional purpose or description
• Machine lifetime
• Token lifetime
• Optional per-machine IP allowlist
• Optional country allowlist
• Optional time-of-day window

The machine lifetime is bounded from one hour to twelve months. The token itself is also time-bounded and can be revoked before use.

Registration flow

The operator runs the generated temp bootstrap command on the target machine. The script generates an Ed25519 keypair locally, sends the public key and token to SikkerKey, and writes the identity files locally.

SikkerKey then registers the temporary machine as pending approval, with its expiration time and guardrails already attached. The configured guardrails are enforced when the machine later sends signed requests.

Temp-machine tokens do not pre-grant projects or secrets. After the machine appears in pending state, the vault owner approves it, attaches it to projects, and grants individual secrets through the same flow used for long-lived machines.

Guardrails

Temporary machines can carry per-machine guardrails that apply on every signed request:

• IP allowlist: request source IP must match one of the configured network ranges
• Geo allowlist: request source country must be in the configured country list
• Time window: request time must fall inside selected weekdays and hours in the configured timezone

These guardrails are separate from vault-wide IP allowlisting and from per-secret access policies. All enabled checks must pass before a secret read succeeds.

Approval and access

A temporary machine uses the same approval and access workflow as a long-lived machine. It appears in the Machines page as pending, then the vault owner approves it, adds it to the right projects, and grants the specific secrets it needs.

This keeps the temp-machine token focused on identity setup, lifetime, and guardrails. Project access and secret access remain deliberate dashboard actions after the machine has registered.

Extension and expiry

Temporary machines can be extended, but only forward and only within a rolling twelve-month remaining lifetime cap. Each extension records the previous expiry, new expiry, actor, timestamp, and optional reason. The most recent un-reverted extension can be reverted.

When the expiry passes, SikkerKey disables the machine automatically and records a temporary-machine expiry audit entry. After 30 days of retention, SikkerKey permanently deletes the expired temporary machine, its project memberships, secret grants, guardrail configuration, and extension history.

Temporary vs ephemeral

Temporary machines and ephemeral machines are both time-bounded, but they solve different problems.

Ephemeral machines are created by reusable enrollment tokens and are auto-approved with preconfigured project and secret grants. They are for automated fleets.

Temporary machines are created by a single-use temp bootstrap token, require manual approval, and receive project and secret access after registration. They are for one bounded machine where the owner wants a deadline and optional perimeter controls attached to that identity.