Skip to content

The six-layer model

Target audience: Solution Architects, Enterprise Architects

Reading time: 15 minutes

Prerequisites: Deployment organization model — Overview

Introduction

The deployment organization model is composed of six logical layers. Each layer expresses a distinct governance concern and contains a small number of entities that together answer one architectural question.

This page describes the layers in depth. The detailed entity definitions live in the Entity reference.

flowchart TB
    subgraph ORG["Organizational layer<br/><i>Who owns this cryptographic domain?</i>"]
        direction LR
        DEP["Deployment"]
        TEN["Tenant"]
        APP["Application"]
    end

    subgraph IDENT["Operational identity layer<br/><i>Who is performing this action?</i>"]
        direction LR
        ACT["Cryptographic Actor"]
        CRED["Credential"]
    end

    subgraph EXCH["Governed exchange layer<br/><i>What is the business context?</i>"]
        CTX["Exchange Context"]
    end

    subgraph RES["Cryptographic resource layer<br/><i>What can be done, on what?</i>"]
        direction LR
        ASSET["Cryptographic Asset"]
        CAP["Capability"]
    end

    subgraph CTRL["Control layer<br/><i>What is the party authorized to do?</i>"]
        direction LR
        GRANT["Capability Grant"]
        CONSTR["Constraint Policy"]
        POL["Policy"]
    end

    subgraph EVID["Evidence layer<br/><i>What happened, by whom, with what result?</i>"]
        AUDIT["Audit Event"]
    end

    ORG --> IDENT --> EXCH --> RES --> CTRL --> EVID

    style ORG fill:#e8f4f8,stroke:#1a5276
    style IDENT fill:#fdebd0,stroke:#d68910
    style EXCH fill:#d6eaf8,stroke:#2980b9
    style RES fill:#d5f5e3,stroke:#1e8449
    style CTRL fill:#fadbd8,stroke:#c0392b
    style EVID fill:#e8daef,stroke:#7d3c98

Layer 1 — Organizational

Question answered: Who owns this cryptographic domain?

The organizational layer establishes structural ownership: the boundaries within which cryptographic governance operates. It defines the deployment, the tenants that operate within it, and the applications under each tenant.

Entities:

  • Deployment — the complete installation of ANKASecure© with its compliance baseline and HSM integration
  • Tenant — an isolated cryptographic domain within a deployment
  • Application — a business system or functional domain (Core Banking, Card Issuance, CRM)

Design principle: ownership is hierarchical and explicit. A deployment defines the regulatory frame within which tenants operate; a tenant scopes the applications it owns; an application contextualizes the operational identities that act under it.

What this layer enables: organizations with multiple business units, multiple regulatory regimes, or multiple legal entities can structure their cryptographic governance to match the way the business itself is structured. The model does not impose a flat structure.

Layer 2 — Operational identity

Question answered: Who is performing this action?

The operational identity layer defines the runtime subjects that execute cryptographic operations. It separates the concept of what authenticates (the credential) from what acts (the actor).

Entities:

  • Cryptographic Actor — the operational subject (an internal service, a batch job, a third-party system, a BPO processor)
  • Credential — the authentication mechanism the actor uses (client_id + secret, mTLS, OIDC, etc.)

Design principle: identity at runtime is the actor, not the credential. An actor may rotate credentials independently of its authorization grants. This separation makes secret rotation a non-event for governance.

What this layer enables: the model treats internal services and external parties as the same kind of subject — a Cryptographic Actor. Authorization decisions, audit events, and rate-limit enforcement anchor on the actor regardless of whether it sits inside the enterprise or outside it.

Layer 3 — Governed exchange

Question answered: What is the business context of this operation?

The governed exchange layer is the layer that distinguishes a cryptographic control plane from a traditional KMS. It models the business interaction in which a cryptographic operation takes place.

Entities:

  • Exchange Context — a governed interaction scenario (Card Embossing — VISA, BPO Collections, Regulatory Reporting)

Design principle: authorization is bound not only to identity and resource, but to the business relationship in which the action takes place. The same actor may have different authorizations in different exchange contexts — and a context may be suspended or terminated as a single governance act.

Attributes of an Exchange Context: owning application, counterparty, direction (OUTBOUND, INBOUND, BIDIRECTIONAL, INTERNAL), business purpose, sensitivity level, status.

What this layer enables: when a third-party relationship is renegotiated or terminated, the cryptographic implications propagate immediately through the affected Exchange Context — without auditing every grant the third party may hold.

Layer 4 — Cryptographic resource

Question answered: What can be done, and on what material?

The resource layer represents the cryptographic substrate: the material that holds entropy and the functions that operate on it. It separates the thing (asset) from the operation (capability).

Entities:

  • Cryptographic Asset — managed key material (symmetric, asymmetric, post-quantum, hybrid, wrapping keys)
  • Capability — a cryptographic function (encrypt, decrypt, sign, verify, reencrypt, resign, wrap, unwrap, derive)

Design principle: consumers never receive keys; they invoke capabilities. The asset is referenced by stable identifier, and the runtime resolves the appropriate version based on policy and lifecycle state.

What this layer enables: crypto-agility. An asset's underlying algorithm or version can change without affecting consumers, because consumers reference capability + asset identifier — not the algorithm. This is the substrate that makes Policy-Driven Crypto-Agility operational.

Layer 5 — Control

Question answered: What is this party authorized to do, and under what conditions?

The control layer is where identity, resource, and exchange context bind into an authorization. It is the convergence point of the model.

Entities:

  • Capability Grant — the binding of Actor + Capability + Asset + Exchange Context + Constraints
  • Constraint Policy — restrictions on how the capability can be used (time window, max usage, batch scope, rate limit, contextual requirements)
  • Policy — global or scoped rules governing platform behavior (algorithm catalog, lifecycle rules, compliance constraints)

Design principle: authorization is fine-grained. A grant answers four questions in a single record:

  1. Who can act? → the Actor
  2. What can they do? → the Capability
  3. On what assets? → the Cryptographic Assets
  4. Under what conditions? → the Constraints, scoped to an Exchange Context

What this layer enables: authorization decisions that reflect the full governance reality — not only access control, but bounded use. A grant can be one-shot, batch-scoped, time-windowed, rate-limited, or conditional on contextual signals. Revoking a grant immediately removes the actor's ability to invoke the capability, without affecting other grants.

Constraint Policy versus Policy: Constraint Policies bind to specific Capability Grants and govern individual authorizations. Policies govern the platform globally or at architectural levels (deployment, tenant, exchange context, asset, capability). The two are complementary: Policies define what is allowed in principle; Constraint Policies define what is allowed in this particular grant.

Layer 6 — Evidence

Question answered: What happened, when, by whom, with what result?

The evidence layer captures every authorization decision and every cryptographic operation. It is the audit substrate of the control plane.

Entities:

  • Audit Event — a structured record of an operation or decision

Design principle: auditability is a first-class property of the model, not an add-on. Every grant evaluation, every cryptographic operation, every constraint check produces an audit record. Both allow and deny outcomes are captured.

Captured per event: organizational scope (deployment, tenant), operational subject (application, actor), credential used, exchange context, capability invoked, asset involved, constraints applied at decision time, outcome with reason, timestamp, trace identifiers.

Integrity guarantee: audit events are HMAC-signed at production time and stored in an isolated audit data store. They support compliance reporting, incident response, forensic analysis, and continuous monitoring.

What this layer enables: the organization can reconstruct, at any future moment, exactly what happened: who acted, on which key, in which business context, under which restrictions, with what outcome. This evidence base is the foundation for compliance with frameworks such as DORA, PCI-DSS, SOX, and GDPR.

How the layers compose

The six layers are not independent silos. They compose at runtime: every cryptographic invocation traverses them in sequence, and the answer to each layer's question becomes input to the next.

flowchart LR
    L1["Organizational<br/>Who owns?"]
    L2["Operational identity<br/>Who acts?"]
    L3["Governed exchange<br/>What context?"]
    L4["Cryptographic resource<br/>What material?"]
    L5["Control<br/>Authorized?"]
    L6["Evidence<br/>Recorded"]

    L1 --> L2 --> L3 --> L4 --> L5 --> L6

    style L1 fill:#e8f4f8,stroke:#1a5276
    style L2 fill:#fdebd0,stroke:#d68910
    style L3 fill:#d6eaf8,stroke:#2980b9
    style L4 fill:#d5f5e3,stroke:#1e8449
    style L5 fill:#fadbd8,stroke:#c0392b
    style L6 fill:#e8daef,stroke:#7d3c98

The detailed runtime flow — including the decision logic that traverses these layers — is described in Relationships and runtime flow.

Next steps