HATS Technical Specification

HATS is a publicly available technical conformance standard for continuous AI trustworthiness; certification under HATS provides independently verifiable evidence that a system satisfies the standard's defined controls. This document provides a technical overview of the HATS specification: its verification architecture, node model, hash and signature requirements, replay semantics, and conformance levels. For the full specification, see the HATS Standard.

Architectural Overview

HATS operates on a verification model where security controls are not assumed to exist because someone checked a box on a form. Instead, each control is independently verified by a HATS-compliant node at regular intervals, and each verification produces a cryptographically signed attestation record. The aggregate of these records forms a tamper-evident chain that constitutes proof of control state over time.

The architecture has three layers. The verification layer consists of HATS nodes that perform the 20 defined checks against target systems. The attestation layer receives verification results, signs them with post-quantum signature schemes, and chains them into a tamper-evident sequence. The anchor layer writes periodic commitments to external ledgers (Bitcoin, Ethereum, or other systems that provide public, immutable timestamping).

Each layer operates independently. Verification nodes can be deployed on-premises, in cloud environments, or at the network edge. The attestation layer can be operated by the organization being verified, by a third-party verifier, or by a hybrid arrangement. The anchor layer is agnostic to the specific ledger used for timestamping.

The 20 Verification Checks

HATS defines 20 verification checks organized into five domains. Each check has a unique identifier, a specification of what constitutes a pass or fail, and a recommended verification interval.

Domain 1: Identity and Access (Checks 1-4). Check 1 verifies that multi-factor authentication is enforced for all administrative access. Check 2 verifies that privilege escalation paths are audited and logged. Check 3 verifies that service account credentials are rotated within the declared rotation period. Check 4 verifies that identity federation configurations match the declared security policy.

Domain 2: Data Protection (Checks 5-8). Check 5 verifies that data-at-rest encryption uses algorithms that meet the declared security level. Check 6 verifies that data-in-transit encryption is enforced on all external interfaces. Check 7 verifies that key management procedures match the declared key lifecycle policy. Check 8 verifies that backup encryption is independent of production encryption keys.

Domain 3: Network Security (Checks 9-12). Check 9 verifies that network segmentation matches the declared architecture. Check 10 verifies that ingress filtering rules match the declared policy. Check 11 verifies that egress filtering is active and that anomalous outbound traffic triggers alerts. Check 12 verifies that DNS resolution is protected against cache poisoning and that DNSSEC is enabled where declared.

Domain 4: Application Security (Checks 13-16). Check 13 verifies that deployed application versions match the declared inventory and that no known critical vulnerabilities exist in the deployed stack. Check 14 verifies that API endpoints enforce authentication and rate limiting as declared. Check 15 verifies that secrets management systems are operational and that no secrets are exposed in configuration files, environment variables, or source repositories. Check 16 verifies that web application firewalls or equivalent filtering layers are operational and configured according to the declared policy.

Domain 5: Operational Security (Checks 17-20). Check 17 verifies that logging infrastructure is operational and that log integrity is protected. Check 18 verifies that incident response automation (if declared) is functional and produces expected responses to test inputs. Check 19 verifies that system configuration matches the declared baseline and that drift is within declared tolerance. Check 20 verifies that the HATS monitoring infrastructure itself is operational, producing a self-referential integrity check that prevents silent monitoring failures.

The 8 Node Types

HATS defines 8 node types, each with specific roles in the verification and attestation pipeline.

Verifier Nodes (Type 1) perform the actual verification checks against target systems. A Verifier node must have the credentials and network access needed to perform its assigned checks, and it must produce a signed verification result for each check execution. Verifier nodes are the only node type that directly interacts with the systems being verified.

Attestor Nodes (Type 2) receive verification results from Verifier nodes and produce the cryptographically signed attestation records. Attestor nodes hold the signing keys and are responsible for the integrity of the attestation chain. They verify the signature on incoming verification results before incorporating them into the chain.

Relay Nodes (Type 3) transport attestation records between Attestor nodes and other components. Relay nodes do not sign or modify attestation records; they verify signatures on records they transport and reject any record with an invalid signature.

Anchor Nodes (Type 4) write periodic commitments (hash digests of the attestation chain state) to external ledgers. Anchor nodes do not need access to the full attestation chain; they receive pre-computed commitment values from Attestor nodes.

Archive Nodes (Type 5) store the complete attestation history and serve historical queries. Archive nodes verify the integrity of the chain as they store it and can detect any corruption or modification.

Replay Nodes (Type 6) provide the replay verification service: given a point in time and a set of checks, the Replay node can reproduce the attestation state at that moment and verify that the declared control state is consistent with the attestation chain. Replay is the mechanism by which historical claims about control state are verified.

Gateway Nodes (Type 7) provide the external API for verification queries. When a third party (such as an insurer or auditor) requests verification of an organization's HATS status, the Gateway node processes the query against the attestation chain and returns a signed response.

Monitor Nodes (Type 8) observe the health of the HATS infrastructure itself. Monitor nodes perform Check 20 (the self-referential integrity check) and alert on infrastructure failures, missed check intervals, or chain integrity violations.

Hash Profiles

HATS supports multiple hash profiles to accommodate different security requirements and performance trade-offs. Each profile specifies the hash algorithm used for chain integrity, attestation binding, and commitment generation.

Profile SHA3-256 (default). Uses SHA3-256 (FIPS 202) for all hash operations. This profile provides 128-bit security against collision attacks and is resistant to length extension attacks. SHA3-256 is the mandatory minimum for HATS conformance.

Profile SHA3-512. Uses SHA3-512 for all hash operations, providing 256-bit collision resistance. This profile is recommended for organizations requiring long-term archival security or operating in environments where regulatory requirements specify 256-bit security levels.

Profile SHAKE-256. Uses SHAKE-256 as an extendable output function, producing variable-length digests as needed by specific protocol components. This profile is used internally for key derivation and for generating commitment values of non-standard lengths.

All hash profiles produce chain entries that include the profile identifier, ensuring that chain verification uses the correct algorithm for each entry. Mixed-profile chains are permitted when upgrading from one profile to another; the transition point is itself attested.

Signature Requirements

Every attestation record in a HATS chain must be signed with at least one post-quantum signature scheme from the NIST-approved set. The mandatory minimum is ML-DSA-65 (FIPS 204). For enhanced security, HATS recommends the three-key signing configuration: ML-DSA-65 + FALCON-512 + SLH-DSA-SHA2-128f-simple, which provides security against the simultaneous compromise of three independent mathematical hardness assumptions (MLWE lattices, NTRU lattices, and stateless hash functions).

Classical signature schemes (ECDSA, Ed25519, RSA) are permitted as supplementary signatures during a transition period but do not satisfy the HATS signature requirement on their own. The transition period is defined as ending on the earlier of: (a) three years from the date of NIST's final standardization of FIPS 204/206, or (b) the date on which a cryptographically relevant quantum computer is demonstrated.

Replay Semantics

Replay is the core verification mechanism in HATS. Replay semantics define how a historical control state can be verified from the attestation chain.

A replay query specifies a timestamp and a set of checks. The Replay node locates the attestation records immediately preceding and following the specified timestamp for each requested check. It verifies the signatures on those records, verifies the chain integrity between them, and returns the verified control state at the requested time.

Replay queries are deterministic: given the same attestation chain and the same query parameters, any Replay node will return the same result. This determinism is what enables independent verification. An insurer, auditor, or regulator can operate their own Replay node, load the same attestation chain, and independently verify any historical control state claim.

Replay resolution is bounded by the check interval. If a check runs every 10 minutes, the replay resolution for that check is 10 minutes. HATS does not interpolate between check results. If a check passed at 14:00 and the next check is at 14:10, a replay query for 14:05 reports the 14:00 result with a notation that the next verification occurs at 14:10.

Conformance Levels

HATS defines three conformance levels that reflect different scopes and depths of attestation.

Level 1: Foundation. Requires attestation of at least 12 of the 20 checks, including all checks in Domain 1 (Identity and Access) and Domain 2 (Data Protection). Requires SHA3-256 hash profile. Requires at least ML-DSA-65 signatures. Requires check intervals of no more than 60 minutes. Requires chain anchoring at least once per 24 hours.

Level 2: Comprehensive. Requires attestation of all 20 checks. Requires SHA3-256 or SHA3-512 hash profile. Requires at least two PQ signature schemes (ML-DSA + one additional). Requires check intervals of no more than 15 minutes. Requires chain anchoring at least once per 6 hours.

Level 3: Continuous. Requires attestation of all 20 checks. Requires SHA3-512 hash profile. Requires the full three-key PQ signature configuration (ML-DSA + FALCON + SLH-DSA). Requires check intervals of no more than 5 minutes. Requires chain anchoring at least once per hour. Requires real-time attestation streaming to designated verification endpoints.

Organizations self-declare their target conformance level and are evaluated against the requirements of that level. A Level 2 declaration that is fully met is stronger than a Level 3 declaration with gaps.

Implementation References

The HATS specification is implementation-agnostic. Any system that produces attestation records conforming to the specified format, signed with the required algorithms, and organized into the specified chain structure satisfies the standard. Reference implementations are available through the Conformance Suite, which provides test vectors, chain validation tools, and signature verification utilities.

For information on how HATS integrates with cyber insurance underwriting, see the Attested Risk Addendum. For how HATS compares to existing frameworks, see Market Positioning. For regulatory alignment, see HATS and the EU AI Act.