Eight questions.
To ask any platform that proves and controls.
Choosing the platform that proves identity and controls what acts is an architecture decision, and architecture decisions get audited. Here are eight questions that decide whether a platform survives the review. They're vendor-agnostic: take them into any evaluation, including ours. Each one maps to a control you can check the evidence for. Our answers are below.
Eight questions that decide it.
Each question screens for a failure mode an architecture review should catch. The control chip links the evidence on the coverage map.
Where do private keys live, and can they leave?
Screens for
Credentials that can be exported, synced, or copied off the device. If a key can leave, it can be stolen at rest or in transit, and a phished or malware-hit endpoint takes the key with it.
Our answer
Keys are generated in the device secure enclave and never exported. Server-side operations run in HSMs validated to FIPS 140-3. The standard backs the distinction: synced passkeys cap at AAL2, and AAL3 needs a hardware-bound, non-exportable key (NIST SP 800-63B Supplement 1, 2024).
Is it phishing-resistant by construction, or by training?
Screens for
Flows that stay phishable in real time. A one-time code or an approval prompt can be relayed by an attacker in the middle while the user does everything right.
Our answer
Origin-bound signatures. The credential signs for the real origin, so a relayed or look-alike site gets nothing to replay. Phishing resistance is a property of the construction, not something users have to get right.
What's covered beyond web login?
Screens for
Deployments where strong authentication stops at the browser. Voice, the help desk, frontline shared devices, and person-to-person flows fall back to knowledge questions and the last four digits.
Our answer
One rail, eight surfaces: voice, web, people, frontline, agents, machines, bots, and workloads. The same cryptographic identity covers the channels that usually get left on legacy auth.
Does a high-impact action get its own approval, or does a session cover it?
Screens for
Models where one login authorizes everything that follows. A session token that opens the door also signs the wire transfer, and an agent on a stale session inherits the whole blast radius.
Our answer
Signed, action-bound human consent on high-impact actions, with dual-control (Lockstep) gating the highest-impact ones behind two people. The approval binds to the action, not the session.
Can you verify the audit trail, or do you take the vendor's word?
Screens for
Logs the vendor holds, formats, and can edit. If the sole record of what happened lives in the vendor's system, your evidence is as good as their integrity and their uptime.
Our answer
Customer-signed, tamper-evident chains you hold. Anyone with the chain verifies it with the open scramble-audit-verify CLI, and it holds even if we're gone. You verify it yourself.
How fast does revocation propagate, and how far?
Screens for
Cached sessions that outlive the kill switch, and deprovisioning that means hunting an identity across every system by hand. Slow or partial revocation is a window an attacker lives in.
Our answer
One action, rail-wide. Kill a credential, an agent, or a workload identity and it's gone everywhere the rail runs, not chased system by system.
Is the help-desk reset path inside the security model, or outside it?
Screens for
A hardened front door with a soft side entrance. If account recovery and help-desk resets fall back to knowledge questions, that's where social engineering walks in.
Our answer
Cryptographic proofing on the reset path, the same primitive as the front door. The help desk verifies the person with a signature, not a security question.
Do non-human identities get the same primitive, or a second system?
Screens for
Service accounts, machines, and workloads left on vaulted shared secrets and rotation schedules. A second credential model means a second blast radius and a second thing to operate.
Our answer
The same primitive: asymmetric keys, signed assertions, short-lived tokens (RFC 7523). No shared secret on the wire, nothing in a vault to rotate. Agents, machines, bots, and workloads ride the rail humans do.
The ninth thing is the rollout.
Ask it anyway: does this overlay what I run, or replace it? ScrambleID federates with the IdP you already operate, Okta, Entra, Ping, ForgeRock, anything OIDC or SAML. Nothing to rip out, and production-ready two weeks from contract. The eight questions test the architecture. This one tests whether you can actually deploy it.
Take these into any evaluation. Including ours.
Steal the sheet. Hand these eight questions to every platform on your list, ours included, and weigh the answers. When you want ours under the microscope, bring your hardest architecture reviewer.