Does customer data leave the enclave?

No. What leaves is metadata, counts, hashes, finding and POA&M summaries and register entries. Two validators reject anything else before a bundle is written, and a boundary attestation is written only after they pass. Things that do leave, none of them customer CUI: summaries to Trust Codex, managed-identity queries to Azure and Microsoft Graph, CVE identifiers to the NIST NVD for enrichment (can be disabled), administrative audit events to the MacTech Suite, and auditor-invitation e-mails.

Is EnclaveWatch a SIEM or an EDR?

Neither. It is right-sized monitoring for one CMMC Level 2 enclave. It aggregates Defender evidence; it does not replace Defender. It tracks Defender Vulnerability Management findings; it is not a vulnerability scanner.

Who decides MET or NOT MET?

Trust Codex, against the evidence EnclaveWatch sends. EnclaveWatch produces evidence; it does not adjudicate compliance.

EnclaveWatch

Machine-collected evidence. Machine-detected drift. Human-approved remediation.

EnclaveWatch runs inside the MacTech CUI Vault. Every week it executes the hardening and Azure/Entra validators, writes content-addressed forensic packets into a signed hash chain, republishes an evidence library with a folder for every control, and sends Trust Codex a bundle of metadata and hashes. Raw logs never leave.

Every number below is counted from the EnclaveWatch repository's own catalogs by scripts/build-spec-sheet-numbers.py (vendored 2026-09-16, commit 870ace6). Sources are listed per row.

Vault + EnclaveWatch tier Which controls it carries for you

71
Catalogued checks
28 Azure · 24 OS · 5 Entra · 4 chain-of-custody · 10 self-state
97
Hardening checks per run
Windows Server 2025 canonical validator
84 / 110
Controls machine-evidenced
26 are governance-only by nature
239 / 320
Objectives with vault evidence
199 STRONG · 74 PARTIAL · 4 MODERATE sources
191
Event types catalogued
10 correlation rules
Weekly
Signed canonical run
Sunday 02:00, 10-day staleness backstop

Spec sheet

Item	Value	Source
Catalogued checks	71 (3 critical, 41 high, 26 medium, 1 low)	EnclaveWatch/config/check-catalog.json
Controls referenced by checks	39 controls across 11 families (AC, AU, CA, CM, IA, IR, MA, MP, RA, SC, SI)	EnclaveWatch/config/check-catalog.json
OS hardening validator	97 checks executed per canonical run	EnclaveWatch/src/EnclaveWatch.Infrastructure/CanonicalChecks/Test-CuiHardening.ps1
Azure / Entra validator	15 controls, plus per-Conditional-Access-policy and per-NSG-rule sub-checks	EnclaveWatch/src/EnclaveWatch.Infrastructure/CanonicalChecks/validate_azure_entra.py
In-process evaluators	15 Azure posture · 5 OS posture · 5 chain-of-custody · 5 Entra collectors · 5 event collectors	EnclaveWatch/src/EnclaveWatch.Infrastructure/DependencyInjection.cs
Event catalogue	191 Windows/Azure event types, 21 families; 10 correlation rules	EnclaveWatch/config/audit-event-catalog.json, EnclaveWatch/config/correlation-rules.json
Controls / objectives mapped	110 controls, 320 assessment objectives, 14 families	EnclaveWatch/config/evidence-library-map.json
Evidence sources bound	277 (175 OS bundle · 97 forensic · 4 governance · 1 export artifact)	EnclaveWatch/config/evidence-library-map.json
Coverage class	84 technical-automated · 26 governance-only	EnclaveWatch/config/evidence-library-map.json

Cadence

Canonical evidence run (hardening + Azure/Entra validators): Weekly, Sunday 02:00 vault-local; 10-day staleness backstop; catch-up on startup
Event collectors (Windows event log, Azure activity, break-glass, drift, Defender): Every 1 minute
Correlation → alerts: Every 1 minute
OS posture evaluators: Every 1 hour
Azure posture evaluators · Entra collectors: Every 6 hours (24-hour sign-in lookback)
Chain of custody · maintenance sessions · asset inventory · cadence-miss detectors: Every 24 hours
Evidence library republish: Every 12 hours, after every canonical run, and on demand
Break-glass watch · configuration drift: Every 300 seconds
Defender critical alerts: Every 600 seconds

What it produces

Trust Codex weekly bundle

12 files: review acknowledgement, finding summary, POA&M recommendations, manifest hashes, control-mapping summary, SSP implementation status, evidence-quality summary, catalog versions, boundary attestation, review attestation, export manifest, SHA-256 list

Forensic packets

One content-addressed packet per check (command issued, rule expected, value observed, adjudication), sorted and threaded into an HMAC-signed hash chain per run

Evidence library

A folder for every one of the 110 controls, byte-for-byte artifact copies, per-control manifest, signed index, three-layer verification

Assessor binder

ZIP per request: implementation status, validation results, findings, POA&Ms and reviews per control, with cover and hash list

Daily and weekly manifests

Canonically serialised, signed

Data egress

Customer data exported: none.

What leaves the vault is metadata, counts, hashes, finding and POA&M summaries and register entries. Two validators fail the whole export if anything else is present: a seven-key denylist (raw event XML and body, command lines, passwords, secrets, private keys) and a content scan for raw PowerShell, Windows event XML and unredacted paths. The boundary attestation is written only after both pass. Customer CUI never transits the vault at all: uploads go from the browser straight to Azure Blob, and the vault records a transaction id, a content hash and a size.

What does leave, and where

Trust Codex: summaries, counts, hashes, register entries.
Azure, Resource Graph, Microsoft Graph, Defender: outbound queries authenticated by managed identity.
NIST NVD: CVE identifiers derived from the enclave's vulnerability posture, for enrichment. 24-hour cache. Can be disabled.
MacTech Suite: administrative audit events (allow-list grants, replay rejections, proxy drift). Not customer data.
Resend: auditor invitation and intake-token e-mails.

What it proves

Host configuration state at run time, per check, with the command issued, the rule expected, the value observed and a hash.
Azure and Entra control-plane state at run time: exposure, storage and Key Vault protections, Front Door TLS and WAF, RBAC, Policy, Defender for Cloud score, Activity Log diagnostics, Conditional Access, MFA registration, PIM, Global Administrator count, break-glass exclusions.
That specific catalogued events occurred, and which correlation rule they matched.
That the human cadences happened, or did not: weekly ISSO review signed, monthly access review, 90-day restore test, maintenance sessions, break-glass activations. A miss is recorded as missing, not hidden.
Integrity of its own record: per-run hash chains, a signed library index, catalog SHA-256s pinned on every export, and a boundary attestation that no forbidden key left the vault.

What it infers

Each claim carries its window and degrades to stale when it closes.

A control is still met between canonical runs: last run within 7 days (Codex freshness budget); scheduler backstop 10 days
Entra sign-in behaviour: 24-hour sample, every 6 hours
Configuration drift attribution: Sysmon events correlated ±60 minutes against a 14-day change log
Defender alert completeness: 7-day backfill on first run, then 600-second polls
Library evidence freshness: flagged stale after 45 days
Dormant accounts: no logon for 90 days
Incident candidates: correlation rules flag candidates for triage; EnclaveWatch never declares an incident

What it cannot prove

No endpoint or fleet visibility. There is no agent; the only asset it sees is the vault host.
No Microsoft 365 or GCC High collectors. Sovereign-cloud support is an untested base-URL override.
No STIG or SCAP content. That is a separate MacTech product, the public STIG server.
No retention guarantee yet. No retention policy or purge job exists for its event store; a retention figure will appear here when one does.
One vault per deployment. Vault and customer identifiers are configuration, not tenancy.
Binaries are not yet code-signed; releases are verified by hash.
A vault administrator who can read the local signing key can re-sign the local record. Off-host anchoring is Trust Codex's witness ledger, not EnclaveWatch's.
Between runs the hardening and Azure/Entra validations are point-in-time; collectors and posture evaluators are what run continuously.

Questions assessors ask

Does customer data leave the enclave?: No. What leaves is metadata, counts, hashes, finding and POA&M summaries and register entries. Two validators reject anything else before a bundle is written, and a boundary attestation is written only after they pass. Things that do leave, none of them customer CUI: summaries to Trust Codex, managed-identity queries to Azure and Microsoft Graph, CVE identifiers to the NIST NVD for enrichment (can be disabled), administrative audit events to the MacTech Suite, and auditor-invitation e-mails.
Is EnclaveWatch a SIEM or an EDR?: Neither. It is right-sized monitoring for one CMMC Level 2 enclave. It aggregates Defender evidence; it does not replace Defender. It tracks Defender Vulnerability Management findings; it is not a vulnerability scanner.
Who decides MET or NOT MET?: Trust Codex, against the evidence EnclaveWatch sends. EnclaveWatch produces evidence; it does not adjudicate compliance.

See the vault tiers Our own enclave's numbers