insider threat key management

Insider threat and cryptographic keys: why human-process controls run out of road

Every mature security program has insider-threat controls: separation of duties, four-eyes approvals, periodic access reviews, privileged-session recording. They reduce the probability of misuse and increase the probability of detection. They do not change the underlying fact: somewhere, a sufficiently privileged person can read or assemble the key. Cryptographic non-possession changes that fact, there is no key for an insider to access between authorised events.

By Sue Pontius, Chief Executive Officer, Lokblok · Published 22 April 2026

Where human-process controls hit their ceiling

Dual control assumes the two operators are independent. In practice, organisational pressure, deadlines, and shared reporting lines collapse independence. The most damaging breaches of the past decade have not been single-operator failures, they have been small-group failures where the controls existed but the dynamics did not enforce them.

Privileged-session recording is forensic, not preventive. By the time the recording is reviewed, the key has been copied. Access reviews assume the reviewer can tell legitimate access from illegitimate; for cryptographic operations, this distinction is often invisible at the access-control layer.

Rotation reduces the lifetime of any single compromise. It does not reduce the per-event blast radius and it relies on the very same operators to execute the rotation correctly.

Cryptographic non-possession

Zero-persistence reconstruction inverts the question. The operator does not hold the key, ever. Between operations there is only public Regen Token material; during an operation, the key is reconstructed inside a secure element, used once, and destroyed before the response returns. An operator with arbitrary administrative access to the platform finds nothing to misuse.

Insider threat controls do not disappear, they continue to apply to the policy engine, the recovery-agent quorum membership, and the application logic. They simply stop being the last line of defence against unauthorised key use, because cryptographic non-possession is now that line.

Side by side

DimensionConventional approachZero-persistence reconstruction
Privileged operator can read the keyYes, by design or by privilege escalationNo key exists to read
Two-operator collusionDefeats dual controlDefeats the policy engine, but no key is exfiltrated
Departing-employee riskRe-key, rotate, auditRemove from quorum and policy; no key material to revoke
Forensic discoverySessions reviewed after the factCryptographic chain proves what happened
Coerced operator (legal or physical)Operator can produce the keyOperator cannot produce a key that does not exist

What this looks like in practice

  • A custodian moving from N-of-M operator approvals to per-operation cryptography stops needing operations staff to be cleared to signing-key-equivalent levels because operations staff never touch signing material.
  • An enterprise CA removes the long-lived intermediate CA key from the offline vault and replaces it with per-operation reconstruction; the 'key ceremony' becomes the everyday flow.
  • A bank with a privileged-access platform binds privileged session approval into the cryptographic chain so a privileged session that did not produce a quorum-authorised signature simply did not produce one.

Related Lokblok material

About the author

Sue Pontius

Chief Executive Officer, Lokblok

Sue Pontius is CEO of Lokblok, where she leads the company's work on zero-persistence cryptography for digital assets, identity, and high-assurance custody.

View LinkedIn profile →

FAQ

Doesn't the policy engine become the new insider-threat target?
It does, and that is a feature. The policy engine has a much smaller, more specific surface than a general key store, and its decisions are co-signed by the recovery-agent quorum. An insider who compromises the policy engine cannot mint signatures on their own; they can at most attempt to push policy changes that the quorum must still approve.
What about the recovery agents themselves, could a malicious agent collude with an insider?
A quorum threshold tolerates a configured number of malicious or unavailable agents. Sound deployments place agents under genuinely independent operational control, different organisations, different jurisdictions, different hardware. A single insider cannot meet quorum alone.
How does this map onto regulatory expectations for separation of duties?
Regulators expect demonstrable separation between request, approval, and execution. A policy + quorum + secure-element model produces that separation cryptographically and records it in the per-operation chain. The regulatory evidence is stronger than process documentation because it cannot be backdated.
Does this remove the need for SIEM and access reviews?
No. SIEM, access reviews, and behavioural monitoring continue to apply to the platform. They simply stop being the last line of defence against key compromise, because there is no key to compromise between authorised events.

Related insights