Temporary Machines

A temporary machine is a registered machine with a fixed expiration timestamp and a set of optional per-machine guardrails. When the timestamp passes, the machine is disabled automatically; until then, it authenticates like any other machine. Temporary machines exist for workloads that need a short, scoped identity rather than a permanent one: pen-test runs, incident response access, data migrations, demo environments, contractor engagements, time-bounded audits.

The lifetime can run from one hour to twelve months. You configure the guardrails upfront, the contractor or operator runs a bootstrap script on their machine, and you approve the registration from the dashboard like any other machine. Extensions are allowed up to a rolling twelve-month remaining lifetime, and the most recent un-reverted extension can be reverted if you change your mind.

How It Differs From Bootstrap and Ephemeral

All three paths end with an Ed25519 keypair on the machine and the public key stored in SikkerKey. The authentication model is identical. Temporary machines layer two extras on top: a deadline and a per-machine guardrail stack.

How It Works

1. You issue a temporary machine token from the dashboard, picking a name, optional description, lifetime, and guardrails
2. SikkerKey returns a single-use bootstrap URL and shows it once
3. You hand the bootstrap command to the operator of the target machine (or run it yourself)
4. The script generates an Ed25519 keypair locally, posts the public key, and registers the machine in pending state
5. You review and approve the machine from the Machines page like any other registration
6. Add the machine to the relevant projects and grant the secrets it needs, the same way you would for a bootstrap-registered machine
7. The machine authenticates for the configured lifetime, with the guardrails enforced on every secret read
8. When the lifetime passes, SikkerKey disables the machine automatically. After 30 days of retention, the row is permanently deleted.

The token expires after its own configured lifetime (default seven days) or as soon as one machine uses it, whichever comes first.

Creating a Token

Open the Machines page, click the + button, and pick Temp Machine from the dropdown to open the Temp Machine Configuration modal.

1. Identity

• Name: a human-readable label for the machine (e.g. temp-migration-aug, pentest-q3). Shown in the dashboard list, the audit log, and applied as the machine's name on registration.
• Description (optional): free-text notes about why this machine exists or where it will run.

The machine's name is set here at token issuance time, not by the bootstrap script. Whatever you type is what the machine is called once it registers.

2. Lifetime

Set the duration using three free-form inputs: months, days, hours. Minimum one hour, maximum twelve months. The modal previews the resulting expiry date as you type.

The lifetime is the time from registration to auto-disable. Extensions afterwards are allowed up to a rolling twelve-month remaining lifetime.

3. Guardrails

Each guardrail is opt-in and composes with the others: a request is rejected if any enabled axis fails. Guardrails layer on top of SikkerKey's standard checks (vault owner active, vault-wide IP allowlist if configured, project membership, secret grant) and any access policy bound to the secret being read.

Time Window

Restrict reads to a recurring time-of-day window on selected weekdays.

• Start / End: HH:MM clock times in 24-hour format
• Timezone: IANA timezone (e.g. Europe/Copenhagen, America/New_York). The dashboard defaults to your browser's timezone.
• Days: weekday chips for Mon through Sun. At least one is required when the axis is enabled.

A read at 02:30 UTC against a window of 09:00–17:00 Europe/Copenhagen on Mon-Fri is rejected outside business hours. The window is evaluated against wall-clock time in the chosen zone, so daylight-saving transitions handle automatically.

IP Allowlist

Restrict the source IP of the machine's requests to one or more CIDR ranges. Distinct from the vault-wide IP allowlist (which gates whether a machine can authenticate at all). This axis is per-machine and only applies to this temporary identity.

Enter one CIDR per line. Both IPv4 and IPv6 are supported.

Geo

Restrict the source country of the machine's requests. Pick countries by name from the full ISO 3166-1 list.

SikkerKey identifies the source country from the request IP and rejects anything from a country not in the list. Default-deny when the country can't be determined: if you opt into a country gate, an unresolvable IP (a freshly-rotated cloud egress, a novel VPN exit) shouldn't quietly slip through. Unresolvable sources are rejected with the same audit signal as a country mismatch.

4. Save

On save, the dashboard shows the bootstrap commands for Linux/macOS and Windows once. This is the only time the token plaintext is displayed; copy the command immediately. Losing it means revoking the token and issuing a new one.

Using the Token

The generated step of the modal gives you a single-use bootstrap command for each platform.

Linux / macOS:

curl -sSL https://api.sikkerkey.com/v1/VAULT_ID/temp-bootstrap/TOKEN | sh

Windows (PowerShell):

iex (irm "https://api.sikkerkey.com/v1/VAULT_ID/temp-bootstrap/TOKEN/ps")

The vault ID in the URL is a second factor. A leaked token alone is not usable without knowing which vault it belongs to.

What the Bootstrap Script Does

1. Checks that openssl and curl (Linux/macOS) or Invoke-RestMethod (Windows) are available
2. Generates an Ed25519 keypair locally
3. Extracts the raw 32-byte public key
4. POSTs the token and public key to /v1/VAULT_ID/temp-bootstrap/register
5. Writes identity.json and private.pem to ~/.sikkerkey/vaults/VAULT_ID/
6. Sets directory permissions to owner-only

The private key never leaves the machine. The machine's name is pulled from the token row server-side, so the script doesn't need to send a hostname.

The token is single-use: after one successful registration, it is marked used and the URL no longer works. If the script fails partway through, you'll need to revoke the unused token and issue a new one.

Approval

Newly registered temp machines appear as pending on the Machines page, marked with a green hourglass icon to indicate they're time-bound. The badge turns orange once the machine is past its expiry.

The approval flow is identical to bootstrap registration:

• Click Approve to allow the machine to authenticate
• Click Deny to reject and permanently remove the registration

Manual approval is the design point: the token doesn't pre-bake projects or secrets, so an unapproved machine has no path to read anything. You decide what it gets access to after you see it register.

After approval, add the machine to projects and grant the secrets it needs the same way you would for a bootstrap-registered machine. There is no separate "temp machine" code path for these operations. Once approved, a temp machine is a normal machine with a deadline and guardrails attached.

Extending and Reverting

Open a temp machine on the Machines page and click Extend to push its expiration further into the future. The extension dialog shows the current expiry, a new-expiry picker, and an optional reason.

Two rules govern extensions:

• Rolling twelve-month cap on remaining lifetime: at any moment after issuance, the new expiry cannot be more than twelve months from now. This means a machine issued for one month and extended four times still can never sit on a runway longer than a year of remaining time. The cap moves with the clock, not the original issuance date.
• Future-only: you cannot extend to a timestamp in the past. The intent is to push the deadline forward, not to retroactively trim the runway.

Each successful extension records a temp_machine_extend audit entry and stores a row in the extension chain with the previous expiry, new expiry, who applied it, and any reason text.

Reverting an Extension

Click Revert on the most recent un-reverted extension to roll the expiry back to the prior value. Only the most recent un-reverted extension can be reverted; you cannot revert into the past, and you cannot un-revert. The action records a temp_machine_extend_revert audit entry.

This is a single-step undo. If you've layered three extensions and want to drop two, revert the most recent, then revert the one that becomes most recent, and so on.

Guardrail Enforcement

Guardrails are evaluated on every signed request the machine sends, immediately after the standard machine-auth checks and before the route handler runs. The evaluation order is:

1. Vault owner account is active
2. Vault-wide IP allowlist (if configured)
3. Machine exists, approved, and enabled
4. Machine has not expired
5. Per-machine IP allowlist (if enabled): source IP must fall inside one of the configured CIDRs
6. Per-machine geo (if enabled): the source country must be identifiable and must be in the allowed list
7. Per-machine time window (if enabled): current time in the configured zone must fall inside the window on an allowed weekday
8. Signature, timestamp, and nonce verification
9. Route-specific authorization (project membership, secret grant, access policy)

A failure on any per-machine axis returns HTTP 403, records a temp_machine_blocked audit entry naming the failing axis, and increments the auth rate limiter for that machine.

Guardrails are evaluated independently of any access policy bound to the secret being read. Both must pass for the read to succeed.

Machine Lifecycle

Active phase

From approval until the configured expiry, the temp machine authenticates like a standard machine, with guardrails enforced on every request. It shows a temp badge on the Machines page alongside its normal status.

Soft-expire

Once the expiry passes, a background job disables the machine on its next sweep (within one minute). Authentication is refused. The row stays in the database so the audit trail remains intact. A temp_machine_expired audit entry is recorded.

Hard-delete (30-day retention)

30 days after the expiry, the machine row, its grants, its guardrail configuration, and its extension chain are permanently deleted. A temp_machine_purge audit entry is recorded per vault owner, listing the names of the removed machines. The identity file on the machine becomes inert; safe to remove.

Revoking

Two revocation paths, depending on what you want to cut off:

• Revoke the token (before registration): the unused bootstrap URL stops working immediately. No machine was ever registered, so there's nothing to clean up. Records a temp_machine_token_revoke audit entry.
• Revoke the machine (after registration): cuts off authentication immediately and deletes the machine, its grants, and its extension chain. Same flow as revoking any other machine. Records a machine_revoke audit entry.

Both paths are immediate and irreversible.

Plan Availability

Each registered temp machine counts toward your overall plan machine limit. Issuing a token does not consume a slot; the slot is taken when the machine registers.

Audit Trail

All temp-machine activity is recorded in the audit log:

Subscribe to email alerts or webhooks for any of these under Settings > Alerts in the dashboard. The temp_machine_blocked action defaults to alert-on by recommendation; a series of blocked requests is the canonical signal that an out-of-scope party has gotten hold of the identity.