Name: Tessera for Windows
Brand: Tessera

The Problem with Perimeter Security

Traditional network-perimeter security works well when all sensitive work happens inside a controlled boundary. In practice, that boundary is constantly crossed: files are shared with coalition partners, archived on removable media, sent by email, or moved to systems outside the organisation's direct control.

When a file leaves the perimeter, it leaves behind the access controls that were protecting it. At that point there is nothing stopping an unauthorised recipient from reading it — or an authorised one from forwarding it further.

          Data-centric security inverts this model. The protection is not
          in the boundary around the data — it is embedded in the data itself. A
          .ztdf archive can only be decrypted by a Key Access Service that
          has evaluated the requester's attributes against the embedded access policy.
          The policy enforces itself regardless of where the file travels.
        

Perimeter Model

Inside network boundary

Secret file — protected

File crosses boundary

No protection — policy lost

Partner / archive / cloud

Anyone can read

Data-Centric Model

Inside or outside boundary

file.ztdf — encrypted + policy bound

File crosses boundary

Still encrypted + policy bound

Decryption attempt

KAS evaluates policy — ALLOW or DENY

How It Works

Three phases, standards-defined at every step.

Protect

The file is encrypted with AES-256-GCM. A unique Data Encryption Key (DEK) is generated per file, then wrapped for the Key Access Service using RSA-OAEP-SHA256 (elliptic-curve KAS keys are also supported). The ABAC access policy — classification level and releasability attributes from the STANAG 4774 label — is bound to the DEK with an HMAC and stored in the manifest. The STANAG 4778 Binding Data Object ties the label to the content with a digital signature: XML-DSIG for documents, files and sidecars, CMS SignedData for the SMTP/MIME profile.

Travel

The result is a .ztdf archive — a ZIP container holding the encrypted payload, the manifest (policy + wrapped DEK), and the STANAG 4774 Confidentiality Label with its ADatP-5636 Object Classification Label (OCL). The archive is completely self-describing. It can be stored, forwarded, archived, or transferred to any other system — the access policy travels with it and cannot be stripped without invalidating the signature.

Enforce

When a user attempts to open the file, the local Tessera agent sends a rewrap request to the Key Access Service, carrying the user's identity token and a DPoP proof (RFC 9449) that binds that token to the requesting client. The KAS verifies the policy binding, evaluates the embedded ABAC policy against the requester's clearance attributes, and either releases the DEK or returns a denial. Decrypted content is served from memory through a virtual drive, so the working copy the user edits never exists as a plaintext file on the local disk.

Architecture

Tessera for Windows is a layered system. The Windows-side components handle the user experience and local operations. The backend components handle identity, policy, and key management.

The local agent runs in the user's own session as a tray application and exposes a loopback API, authenticated with a per-session HMAC. Office add-ins, the Notepad++ plugin, the Explorer integration and both virtual drives communicate exclusively with that agent — they never contact the KAS or the management service directly. This means the backend can be deployed in an isolated network segment without exposing it to the desktop.

The Key Access Service holds no content: only its own key material — optionally in an HSM over PKCS#11 — and the policy distributed to it. No plaintext is ever stored or logged. The management service holds audit records, the SPIF catalogue and KAS configuration, but never holds decryption keys.

Windows desktop

Word Excel PowerPoint Outlook Notepad++ Explorer extension S: and N: drives

↓loopback API, HMAC-authenticated

Tessera agent

↓

Key Access Service

/rewrap — policy evaluation
/kas_public_key
/spifs — SPIF v2.1 / v3.0
/ca — label-signing CA

↓

Management Service

KAS registration
User / domain / policy config
Audit log

↓

Identity Provider

OIDC / JWKS
User attributes & clearance

Windows Components

Office Add-ins

VSTO add-ins for Word, Excel, PowerPoint, and Outlook. Integrate classification label selection, document protection, and label-aware send enforcement into the native Office ribbon. Outlook enforces that emails carry a valid label before sending.

Windows Explorer Integration

Context-menu entries for Protect with Tessera and Open Tessera File on any file type, a padlock overlay on protected files, and Explorer columns showing the classification. Enables .ztdf encryption and transparent decryption without leaving the Windows shell.

Notepad++ Plugin

A native plugin that classifies and protects plain-text and source files, and shows the confidentiality marking as a banner above the editor — the same label pipeline as the Office add-ins, for the editor developers actually use.

Virtual Drives — S: and N:

S: mirrors the local disk with transparent decryption: a .ztdf appears as its plaintext form, and anything saved there is encrypted on close. N: is a Windows Cloud Files sync root backed by the federated storage service, so protected objects replicated between sites appear as ordinary files.

Local Agent

A tray application running in the user's own session — not a Windows service — that orchestrates all local operations: encryption, decryption, label construction, signature verification, KAS communication, and the SPIF-driven attribute URI mapping. The single point of contact for every Windows-side component, reached over a loopback API whose requests are signed with a per-session HMAC.

Kernel Minifilter

A filesystem minifilter that confines an edit session: write-intent opens outside the session directory are refused, and closing the file signals the agent to re-seal it. It is what stops an application quietly writing an unprotected copy somewhere else.

Backend Components

Key Access Service (KAS)

Server-side service implementing the ACP-240 KAS role. Holds the KAS private key — RSA or elliptic-curve, optionally in an HSM — evaluates ABAC policies through Open Policy Agent, and releases Data Encryption Keys only after positive policy evaluation. Runs as a fleet across sites, with domain-scoped ABAC and brokering between domains so a compartmented document is released only when every domain that owns a fragment agrees.

Management Console

Web application providing operator access to KAS configuration, user management, domain and SPIF administration, policy review, audit log, and PKI certificate management. Secured with OIDC.

Identity Federation

OIDC identity provider issuing ADatP-5663 subject claims: the holder's clearance as a structured ADatP-4774 clearance object, Community-of-Interest membership and citizenship. The KAS validates these on every key-release request. Partner identity providers are brokered, so a coalition user authenticates at home and is still evaluated against the local policy.

Security Characteristics

AES-256-GCM payload encryption — authenticated encryption with a unique DEK per file; the GCM tag detects any tampering with the ciphertext.
RSA-OAEP-SHA256 key wrap — the DEK is wrapped with the KAS public key. Only the KAS holding the corresponding private key can unwrap it. Elliptic-curve KAS keys are supported, and the private key can be held in an HSM addressed over PKCS#11.
DPoP-bound key requests — every rewrap carries an RFC 9449 proof-of-possession signed by an ephemeral client key. A stolen access token is useless without the key it was issued against; the KAS rejects any request without a valid proof.
Split keys across domains — a document can be sealed so that several Key Access Services must each grant access before the key can be reassembled (All-Of), or so that any one of them suffices for availability (Any-Of). Compartments become independent key-release decisions rather than a single point of trust.
HMAC-bound ABAC policy — the access policy is bound to the wrapped DEK by HMAC. Altering the policy invalidates the binding and the KAS will refuse the request.
STANAG 4778 XML-DSIG label binding — the STANAG 4774 Confidentiality Label is signed against the content hash. Any modification to the label or the payload breaks the signature.
No plaintext copy left behind — decrypted content is held in memory and surfaced through a virtual drive, so the file the user opens has no plaintext counterpart on the local disk. A kernel minifilter confines the edit session and re-seals the document when it closes, refusing write-intent opens that would land a copy elsewhere.
SPIF-driven ABAC — policy attributes are derived from the XMLSPIF. Classification and category values map to attribute URIs that must be present in the user's identity token.

Standards Implemented

ACP-240

Zero Trust Data Format

The .ztdf archive format and key-access protocol.

STANAG 4774

Confidentiality Labels

XML Confidentiality Label schema; classification level and categories.

STANAG 4778

Binding Data Object (BDO)

XML-DSIG label-to-content binding, CMS SignedData for email; ADatP-4778.2 profiles for OOXML/OPC, XMP, SMTP and detached sidecars.

ADatP-5636

Object Classification Label (OCL)

JSON OCL record; portioning marking strings, document-level and portion-level marks.

XMLSPIF v2.1/3.0

Security Policy

SPIF parsing for policy-driven attribute URI mapping and ABAC.

RFC 8785

JSON Canonicalisation

JCS-canonical form for deterministic HMAC computation over manifest.

RFC 9449

DPoP

Proof-of-possession binding every key request to the client's own key.

ADatP-5663

Federated Identity

Subject claims for clearance, COI membership and citizenship.

View full standards reference →

The Label, in the Application

Classifications are not hard-coded. Everything the user is offered — the levels, their order, and the categories that may qualify them — is read from the domain's XMLSPIF, so the desktop speaks exactly the vocabulary the policy authority published. The screenshots below use TESSERA, a fictional demonstration policy we publish for testing, so that nothing shown here is a real classification marking.

The Tessera protect dialog with the classification list open, showing the five levels of the TESSERA demonstration policy: UNMARKED, INTERNAL, RESTRICTED, CONFIDENTIAL and SECRET. — **The ladder comes from the SPIF.** Selecting a policy repopulates the classification list from that policy's definition — five levels here, in the order the policy ranks them, not alphabetically and not in file order.

The Tessera protect dialog with a completed label: TESSERA policy, SECRET classification, releasable to ARC and SYL, LODESTAR compartment, and a DEMO administrative marking. — **Categories follow the policy's own semantics.** The TESSERA policy declares one tag set of each kind, and the dialog offers each accordingly: *Releasable To* is permissive — any one value admits the holder; *Special Category Designators* is restrictive — a compartment the clearance must explicitly carry; *Administrative* is informative and takes no part in the access decision at all.

Notepad++ showing a document under the TESSERA demonstration policy, with a red classification banner above the text reading TESSERA, SECRET, Releasable To ARC and SYL, Special Category Designators LODESTAR, Administrative DEMO, and the signed-in user. — **The same label, rendered where the work happens.** This marking is not decoration typed into a header — it is read back from the STANAG 4778 binding attached to the file, so it states what the document actually carries. The tick at the right names the identity it was verified against.

Microsoft Word showing a labelled document with the Tessera pane docked above it: a red banner reading TESSERA, SECRET, Rel ARC and SYL, LODESTAR, DEMO, and the signed-in user. — **Word reads the label out of the document itself.** The binding travels inside the `.docx`, in a custom XML part, so the marking survives a copy, a rename and a mail hop — and appears in whichever application opens the file next, not just the one that applied it.

Microsoft Excel showing a labelled workbook with a blue Tessera banner reading TESSERA, CONFIDENTIAL, Rel TCN, EXERCISE, and the signed-in user. — **A different level, a different marking — from the same policy file.** This workbook is CONFIDENTIAL rather than SECRET, released to a coalition group rather than to nations, and carries the informative *EXERCISE* marking. Nothing in the add-in knows what those words mean; it renders what the SPIF defines, including the colour.

The Notepad++ classification banner for a second file, in green, reading TESSERA, INTERNAL, Releasable To TCN and ARC, Administrative DEMO. — **And the banner tracks the level.** The same editor, a different document: INTERNAL, released more widely, rendered in the colour its policy assigns. A marking that never changed would tell the reader nothing.

Microsoft Outlook composing a message, with the Tessera pane docked above it: a red banner reading TESSERA, SECRET, TCN, and Unsigned. — **A message carries its label before it is sent.** The banner is read back from the STANAG 4778 binding on the item itself, not from anything typed into the message — so the classification is on screen while the message is still being written, and it travels with it as a `Binding-Data` header the receiving client reads the same way. The banner says *Unsigned* deliberately, and it is telling the truth: ADatP‑4778.2 §3.5 makes that header plain label XML, with the cryptographic binding carried in the signed MIME envelope around the message rather than in the header. A client that showed a green tick here would be vouching for something it has not checked.

Office, Notepad++, the Explorer columns and the virtual drives all read the same binding through the same pipeline — one policy, read once, applied everywhere.

Standards-Compliant Data-Centric Security