An outsourced process holds your keys
Payroll, claims, KYC, printing, a data-science partner. Somebody outside the company can decrypt the data because that was the only way to let them work on it.
ANKASecure© replaces the long-lived private key an outsourced process usually receives with a capability grant: an exchange context models the counterparty and the keys in scope, the grant names the operations permitted, and a constraint policy enforces four dimensions — a validity window, a total usage cap, a per-minute rate limit and single use. The counterparty workload authenticates with the OIDC token its own platform issues, through workload identity federation, so no ANKASecure© credential is handed over. Every use is recorded with the grant and constraint decision in a signed, tamper-evident audit trail forwardable to a SIEM with the signature preserved, and revoking the grant or suspending the exchange refuses the next call immediately without re-encrypting any data.
Your provider has your private key. It should have a permission.
Outsourcing a process usually means handing over a long-lived key, and a key cannot be scoped, metered or taken back. ANKASecure© replaces it with a capability grant: the counterparty performs only the operations it was granted, within enforced constraints, with every use recorded — and the grant ends the moment you say so.
CISOHead of third-party riskData protection officer
Is this you
Three ways this lands on your desk
A relationship is ending
The contract terminates and the key is still out there. Rotating it means re-encrypting everything it ever protected, so in practice nobody does.
A regulator asks who can decrypt what
The data-processing agreement says the provider may process. It does not say the provider can read everything, forever, from anywhere — but the key does.
Who signs this: A CISO or head of third-party risk who owns the provider relationship, and a data protection officer who has to answer for what the provider can see. If revoking a counterparty means re-encrypting data, this is the conversation.
How it works
Four moves, none of them a key hand-over
The counterparty gets a permission, not material. The permission is checked on every operation and it lives exactly as long as you decide.
Model the relationship
An exchange context names the counterparty, its type and the keys it may touch. It is an entity in the control plane with a lifecycle of its own — created, active, suspended, closed — and every transition is audited.
- exchange context
- counterparty type
Grant a capability, not a key
A capability grant states which operations the counterparty may perform, on which keys, under a constraint policy with four enforced dimensions: a time window, a total usage cap, a rate limit per minute, and single use. Nothing outside the grant is possible, whatever the counterparty holds.
- validFrom / validUntil
- maxUsage
- rateLimitPerMinute
- revokeOnUse
The counterparty brings its own identity
Its workload authenticates with the token its own platform already issues, through workload identity federation. ANKASecure© hands out no credential of its own to keep, rotate or lose.
Every use is evidence; revocation is immediate
Each operation is recorded, signed, with the grant and the constraint decision beside it, and forwards to your SIEM with the signature intact. Revoke the grant — or suspend the exchange — and the next call is refused. The data is untouched; nothing is re-encrypted.
- signed audit trail
- SIEM forwarding
- revoke without re-encryption
Every exchange, with its risk and its evidence
One application in a demo bank, its counterparties, and the sensitivity of every flow between them. Selecting an application names each exchange context — the PSD2 token issuance, the consent revocation — and who is on the other end of it.
Fifteen minutes
What you will actually watch
Live, on a real deployment, with a counterparty of the kind you have. Nothing in this list is a mock-up or a roadmap item.
An exchange context for a provider: counterparty, type, the keys in scope.
A grant with its constraints: decrypt only, one key set, a two-week window, a usage cap.
The provider decrypts within scope. Then asks for an operation outside it, and is refused with the reason.
The grant is revoked. The very next call from the same workload is refused. Nothing was re-encrypted.
The audit trail: every use, the constraint decision, the revocation — signed, in a chain that would show any edit.
Your provider contract, discussed on the deployment rather than on a slide.
What it rests on
The capabilities underneath, with their state
Shipping
Exchange contexts and counterparty types
The relationship as an entity with its own lifecycle — created, active, suspended, closed — every transition audited.
Shipping
Capability grants and constraint policies
Operation and key scope, plus four enforced constraints: time window, usage cap, rate limit, single use.
Shipping
Workload identity federation
A counterparty workload authenticates with the token its own OIDC platform issues; no ANKASecure© credential is handed over.
Shipping
Immediate revocation
A revoked grant, a suspended exchange or a deleted application stops authorizing on the next call, with no re-encryption.
Shipping
Signed audit trail
Every use recorded with its grant and constraint decision, tamper-evident, forwardable to your SIEM with the signature preserved.
Shipping
Role model
Platform, tenant and operator authority kept apart, so the person who grants is not the person who operates.
The framework
Where this sits in CAPA
The Cryptographic Control Plane reference architecture describes each pillar through the scenarios it must handle and one practical test. One of the sovereignty pillar’s scenarios is this solution, word for word.
02
Primary pillar
Cryptographic Sovereignty
Scenario realised
Maintaining revocable cryptographic authority over third parties
Practical test
“Can the organization govern policy across all its trust domains without moving keys, and revoke a third party’s cryptographic authority without re-encrypting the data?”
04
Primary pillar
Cryptographic Governance & Compliance
Scenario realised
Enforcing a new enterprise security requirement
Practical test
“Can the organization prove, by querying the control plane, which policy applied to a given operation, and change that policy centrally?”
05
Supporting pillar
Enterprise Readiness
Scenario realised
Interoperating with external cryptographic ecosystems
Practical test
“Can the control plane be adopted without replacing the identity, KMS/HSM, PKI, or monitoring platforms already in place?”
L3L4–L5
Maturity move
A control plane has to be in place first. On top of it, governing counterparties by grant rather than by key is what the reference architecture calls agile operations and full governance: the authority you extend outward is as revocable as the one you keep inside.
What this does not do
It does not protect data you send to the counterparty in the clear. The grant governs operations on encrypted data inside the plane; anything decrypted and exported is theirs to protect.
It does not manage the counterparty’s own systems. It decides what they may do with your keys; it does not see what they do afterwards with the result.
It does not certify you. ANKASecure© maps its controls to NIST CSWP 39, the GSA PQC Buyer’s Guide and OWASP and hands you the evidence; the determination is still your auditor’s.
After this
The same installation already does these
No new deployment, no second contract for the platform. The grant mechanism that governs a counterparty is the one that governs your own teams.
Bring the provider contract.
The one where they hold your key. Fifteen minutes on a live deployment to replace the key with a permission you can revoke.
Book the demo