ScrambleID's machine-to-machine (M2M) authentication replaces static client secrets and API keys with key-based proof: your service holds a private key, ScrambleID holds the matching public key, and every token request is a fresh signed assertion. This guide covers the admin workflow end to end. For the architectural reasoning, see M2M Authentication Without Secrets; for the cryptographic specifications, the session binding and key lifecycle references are canonical.

How it works in one paragraph

You register a client identity for each service, bot, or workload. The key pair is generated and stays inside your infrastructure (your KMS, HSM, or platform key store); only the public key is registered with ScrambleID. To get a token, the client signs a one-time JWT assertion with its private key. ScrambleID verifies the signature and issues a short-lived, audience-bound access token: minutes of lifetime, not months, so there's nothing standing to steal.

Enroll a client identity

In the ScrambleID admin console, create a client identity for the service. Give it a name your audit trail will thank you for (specific over generic: "payroll-export-job", not "service-1").
Generate the key pair inside your own infrastructure. The private key never leaves it.
Register the public key against the client identity, and scope the client to exactly the resources it needs.

One identity per workload. Shared client identities recreate the shared-secret problem with extra steps.

Issue tokens

The client requests a token by presenting a signed JWT assertion (the standard JWT client assertion pattern). Each assertion is single-use; each issued token is short-lived and bound to the audience it was requested for. Build clients to request fresh tokens per work window rather than caching long: the short lifetime is the security property, not an inconvenience.

Rotate keys

Plan rotation before you need it:

Generate the new key pair and register the new public key alongside the old one.
During the overlap window, ScrambleID accepts assertions signed by either key; in-flight work finishes on the old key while new flows start on the new one.
Retire the old public key once traffic has moved.

The overlap-window mechanics follow the platform's canonical key lifecycle rules; the same model covers user devices and machine clients.

Revoke

Revoking a client identity (or a single key) from the admin console takes effect immediately for new token issuance, and outstanding tokens age out on their short lifetimes. That's the incident math: containment is the seconds it takes to revoke plus the minutes a stolen token has left, not the months a leaked API key would have lived.

After any suspected compromise, review the client's issuance history in the audit log to scope what the key touched before you revoked it.

Where to go next

M2M Authentication Without Secrets: the full architecture, replay protection, and the incident runbook.
Service Account Replacement: migrating existing standing service accounts onto this model.
Admin Console guide: the console itself, roles, and organization settings.