CMMC Level 2 · Auditor surface
Sign in to review the MacTech CUI Vault evidence record.
EnclaveWatch is the read-only ISSO review plane for the MacTech CUI Vault. It surfaces signed-summary metadata
for IR tabletop exercises (IR.L2-3.6.1/2/3) and Annual Risk Assessments (RA.L2-3.11.1),
with the underlying canonical bytes verified by the EnclaveWatch manifest chain. This page exists so you can
verify the access posture before signing in. The actual evidence stays on the customer's vault and never crosses
to the control plane.
Before you click "Sign in"
Two ways auditors arrive here. Pick the one that matches the invitation you received from MacTech compliance.
-
You received an in-tenant audit identity — an
audit-{name}-{engagement}@MacTechSolutions256.onmicrosoft.comusername plus an 8-character Temporary Access Pass (TAP). This is the universal-coverage path; works regardless of your home organization's identity stack.
Do this first: visithttps://mysignins.microsoft.com/?tenantId=8e7b847e-c045-4e30-967b-50bcb01d56dc, sign in with the audit username + TAP, click + Add sign-in method → Passkey, and register using your device's biometric (Touch ID / Face ID / Windows Hello / FIDO2 hardware key). Then come back here and click Sign in. Use the audit username; your passkey satisfies the CA policy. -
You're a B2B guest from your own organization's Entra/M365 tenant — you accepted
a Microsoft B2B invitation and your home tenant already enforces phishing-resistant MFA.
MacTech's tenant inherits that satisfaction via cross-tenant trust
(
isMfaAccepted=true).
Do this first: verify a phishing-resistant factor is enrolled at your home tenant (FIDO2 / WHfB / passkey). If your home tenant only enforces TOTP or SMS, the sign-in below will fail with "Sign-in couldn't be completed" and you'll need to contact compliance@mactechsolutionsllc.com to switch to the in-tenant audit identity path.
Information class
Controlled Unclassified Information (CUI). All data on this surface is handled per DFARS 252.204-7012 and the contractor's NIST SP 800-171 Rev 2 implementation.
Access posture
Azure Front Door WAF + DDoS at the perimeter, NSG service-tag origin lockdown (only AFD anycast can reach the VM), Caddy reverse proxy on the origin with Host preservation, Microsoft Entra ID OIDC with phishing-resistant MFA enforced via Conditional Access, EnclaveWatch reviewer-role gate — every layer logs, and the daily/weekly manifest chain hashes the audit log.
Read-only surface
No data mutation actions are reachable for the Reviewer role.
Every detail-view open is recorded in the Windows Application log
(auditor.tabletop-file-view, auditor.ra-file-view,
enclavewatch.ra-review.opened).
Access chain you're traversing right now
Each layer below was already enforced before this page rendered. Verify each step against the SSP §6.x and §4.2 controls; we cite the section anchor on every step.
-
Azure Front Door — WAF (Prevention mode), DDoS, edge TLS 1.3.
The vault hostname (
vault-001.mactechsolutionsllc.com) CNAMEs to AFD's anycast network. The WAF policy enforces the Microsoft default rule set + bot-protection ruleset, blocking before the request reaches the origin. Origin pull is HTTPS-only with a request-time host-header rewrite so the origin always sees the public vhost the auditor typed. (SSP §6.3.4 SC.L2-3.13.5; CA.L2-3.12.1 boundary defense) -
VM NSG — origin restricted to AFD service tag.
The vault VM's network security group admits inbound 443 only from
AzureFrontDoor.Backend. The origin is unreachable from the public internet; only AFD's anycast egress can connect. SSH (22) and RDP (3389) are restricted to a documented operator IP via separate rules and audited at the management plane. (SSP §4.2 boundary diagram; SC.L2-3.13.1 / SC.L2-3.13.2) -
Caddy reverse proxy on the VM.
Caddy terminates AFD's origin TLS and forwards to EnclaveWatch's local listener at
127.0.0.1:9443withHost+X-Forwarded-Protopreservation so the OIDC handler constructs callback URLs against the public hostname (not loopback). The pre-auth surface (this page +/auth/*+/api/health) is publicly readable so the AFD origin probe stays reachable and the access description renders before authentication. All other routes require the Reviewer-role policy. (SSP §6.5; AC.L2-3.1.3 information flow control) - Microsoft Entra ID OIDC — phishing-resistant MFA enforced. Identity is federated to MacTech's single-tenant Entra ID directory via authorization-code flow with PKCE. The Conditional Access policy "CMMC: Phishing-resistant MFA - EnclaveWatch Vault auditor surface" applies the built-in Phishing-resistant MFA authentication strength to every sign-in to this app — allowing only FIDO2 security keys, Windows Hello for Business, and x509 certificate MFA; rejecting SMS, voice, TOTP, and password-only authentication. Sign-in frequency is 4 hours (re-MFA every half workday). Client credentials live only in machine-scoped environment variables on the vault host — never in source control, never in plaintext on disk. (SSP §6.5; IA.L2-3.5.1 identification, IA.L2-3.5.3 phishing-resistant MFA, IA.L2-3.5.5 cryptographic identifier protection)
- EnclaveWatch reviewer-role gate. After Entra ID-token validation (audience-pinned to this app's clientId, signature-checked against Entra's JWKS, issuer-bound to MacTech's tenant), EnclaveWatch maps the authenticated principal to a Reviewer or Admin role. Reviewers see read-only surfaces only; Admin actions (export, replay, allowlist-grant) require a separate role and are logged at elevated severity. Sessions are 8 hours absolute / 30-minute sliding inactivity timeout, stored in an HTTP-only, Secure, SameSite=Lax cookie that's forgotten on browser close. (SSP §6.5; AC.L2-3.1.1 access enforcement, AC.L2-3.1.10 session lock, AC.L2-3.1.11 session termination)
-
Audit-anchored detail-view logging.
Every detail-view open writes a Windows Application log event
(
auditor.ra-file-view,auditor.tabletop-file-view,auditor.ca-file-view,enclavewatch.ra-review.opened) with timestamp, file, viewer identity (Entraoid), and bundle content hash. The log is collected by the EW collector worker and folded into the daily/weekly manifest chain — so the record of your evidence review is itself cryptographically anchored, observable to MacTech's ISSO, and exportable to the Trust Codex for assessor verification. (SSP §6.6; AU.L2-3.3.1 event capture, AU.L2-3.3.2 user-attributable logging, AU.L2-3.3.5 log-integrity protection, AU.L2-3.3.8 audit-storage protection)
What happens when you click "Sign in"
Step-by-step so you can verify each leg against the SSP's auth narrative.
-
302 to Entra
/oauth2/v2.0/authorize. Your browser follows the redirect withresponse_type=code,response_mode=form_post,code_challenge_method=S256(PKCE), andscope=openid email profile. No tokens are issued yet. - Entra evaluates Conditional Access. Entra confirms you have a phishing-resistant factor enrolled (FIDO2 / Windows Hello / x509 cert / passkey). If not, sign-in is blocked at Entra and never reaches EnclaveWatch. If your last phishing-resistant MFA event was more than 4 hours ago, Entra prompts you to re-satisfy it now.
-
Entra POSTs the auth code to
/auth/clerk-callback(historical path name; predates the Clerk → Entra migration and is preserved through the cutover for stability). EnclaveWatch exchanges the code for an ID token at Entra's token endpoint, validates the signature against Entra's JWKS, and pins the audience to this app's clientId. -
Cookie session issued; Reviewer role mapped.
EnclaveWatch's claims-transformation pipeline reads the Entra subject (
oid) and maps the user to the Reviewer role per the configured role map. The HTTP-only cookie is set on the response and you're redirected to the dashboard at/. Every subsequent request is gated by the Reviewer policy. -
Sign-in event lands in three audit surfaces.
(1) Entra's sign-in log records the auth strength satisfied and the Conditional Access policy result;
(2) Caddy's access log records the request through the proxy;
(3) EnclaveWatch's Serilog request log records the user identity and route. All three are
cross-correlatable by timestamp + Entra
oid.