docs: retire compliance subtree + sweep framework name-drops from prose

Per operator decision the framework-mapping docs are gone. They were aspirational (no audit, no certification, no validated mapping); keeping them around was misleading. Files deleted (1,883 lines): - docs/compliance/index.md - docs/compliance/soc2.md - docs/compliance/pci-dss.md - docs/compliance/nist-sp-800-57.md Hyperlinks removed: - README.md: 'Auditor / compliance' row in the doc table; the '(compliance mapping included)' parenthetical in the positioning paragraph - docs/README.md: the '## Compliance' section table; the 'Auditor / compliance team' reading-order-by-role row Prose name-drops swept across 24 files: - README.md: 'FedRAMP boundary CAs / financial-services policy CAs' → '4-level boundary CAs / 3-level policy CAs'; 'Compliance-grade for PCI-DSS Level 1, FedRAMP Moderate / High, SOC 2 Type II, HIPAA' → cut entirely - getting-started/{quickstart,concepts,examples,why-certctl, advanced-demo}.md: 'compliance' → 'audit' / 'policy'; 'PCI-DSS / SOC 2 / NIST SP 800-57' framework lists cut; ''pci': 'true'' tag example → ''environment': 'production'' - migration/cert-manager-coexistence.md: 'compliance rules' → 'policy rules' - operator/approval-workflow.md: 'Compliance customers (PCI-DSS Level 1, FedRAMP Moderate / High, SOC 2 Type II, HIPAA)' → 'Operators'; entire 'Compliance control mapping' table (PCI-DSS §6.4.5 / NIST SP 800-53 SA-15 / SOC 2 Type II CC6.1 / HIPAA §164.308(a)(4)) deleted; 'compliance contract' → 'two-person-integrity contract'; 'compliance auditors' → 'reviewers' - operator/legacy-clients-tls-1.2.md: 'PCI-DSS v4.0 Req 4 §2.2.5' audit-reference → CWE-326 (kept); 'PCI-DSS Req 4 §2.2.5 attestation' section retitled to 'TLS posture summary' and rewritten without framework framing; 'PCI-DSS, NIST, and major browsers will eventually deprecate TLS 1.2' → 'Major browsers and OS vendors will eventually deprecate TLS 1.2' - operator/database-tls.md: PCI-DSS Req 4 §2.2.5 audit-ref → CWE-319 only; 'PCI-DSS scope' → 'sensitive data'; PCI-DSS Req 4 v4.0 prose footing → cut - operator/runbooks/disaster-recovery.md: 'SOC 2 / PCI procurement-team deliverable' → 'on-call deliverable'; 'compliance auditors' → 'reviewers' - reference/connectors/{acme,aws-acm,azure-kv,globalsign, local-ca,openssl,ssh,index}.md: 'compliance reporting (PCI-DSS §3.6, HIPAA §164.312)' → 'audit reporting'; 'Compliance environments (PCI-DSS Level 1, FedRAMP High, HIPAA)' → 'Regulated environments'; 'compliance audits' → 'audit'; 'FedRAMP boundary CA' pattern names → '4-level boundary CA' (technically descriptive) - reference/protocols/est.md: 'compliance-hook seam' → 'device-state hook seam'; 'compliance gating' → 'device-state gating'; 'est_compliance_failed' → 'est_device_state_failed' - reference/protocols/scep-intune.md: 'Optional compliance check' → 'Optional device-state check'; failure-counter 'compliance_failed' → 'device_state_failed'; 'Conditional Access compliance gating' → 'Conditional Access device-state gating' - reference/intermediate-ca-hierarchy.md: 'FedRAMP boundary-CA deployments where the regulator requires...' → 'Boundary-CA deployments where you want separation of policy and issuing authorities'; pattern A retitled '4-level FedRAMP boundary CA' → '4-level boundary CA' - reference/architecture.md: broken Related-docs link to compliance.md removed; the rest of that block had stale pre-Phase-2 paths (quickstart.md, demo-advanced.md, connectors.md, openapi.md, testing-guide.md, test-env.md) — retargeted to current locations - reference/deployment-model.md: 'SOC 2 evidence-report generator' → 'Audit-evidence report generator' - reference/vendor-matrix.md: 'SOC 2 / PCI auditors paste this into evidence packs' → 'reviewers paste this into vendor-evaluation packs' - contributor/qa-test-suite.md: 'compliance exist' coverage description cut; 'Compliance (PCI / SOC2 / HIPAA-relevant)' risk-class label → 'Audit-relevant' What was kept: - CWE references (legitimate technical pointers) - Microsoft API/feature names that happen to use 'compliance' literally ('Microsoft Graph compliance API', 'device-compliance validators' — these are MS product names, not framework name-drops) - 'NIST PQC' on the landing page (Post-Quantum Cryptography is the actual NIST standard family, not a compliance framework) Verified: zero hyperlinks into docs/compliance/ remain. All 24 ci-guards/*.sh pass locally. qa-doc-seed-count.sh clean. Net diff: 26 files / -1,883 deletions in compliance/ + -32 net across the prose sweep. Companion edits in cowork/ (CLAUDE.md doc-tree summary + WORKSPACE-CHANGELOG.md retirement note) land separately.
2026-06-07 21:21:40 +00:00 · 2026-05-05 05:26:44 +00:00
parent 4ac41c5007
commit 7c134d0575
30 changed files with 112 additions and 2027 deletions
@@ -495,7 +495,7 @@ Short-lived certificates (those with profile TTL < 1 hour) return "good" from OC

 #### Bulk Revocation

-For compliance events requiring fleet-wide revocation (key compromise, CA distrust, mass decommission), certctl supports bulk revocation by filter criteria. The `POST /api/v1/certificates/bulk-revoke` endpoint accepts filter parameters (profile_id, owner_id, agent_id, issuer_id) and creates individual revocation jobs for each matching certificate. Bulk revocation reuses the same 7-step single-cert flow for each certificate — no new issuer notification or audit mechanics. The operation is idempotent: revoking an already-revoked certificate is a no-op. Partial failures are tolerated — if one certificate fails to revoke (e.g., issuer unavailable), the operation continues for remaining certs and returns a summary. A single `bulk_revocation_initiated` audit event logs the operation with filter criteria, operator actor, and summary (total requested, succeeded, failed counts). Audit events for individual certificate revocations record the operator identity separately. The GUI bulk revoke button on the certificates list filters by visible selections and displays an affected-cert count modal before confirmation.
+For incident-response events requiring fleet-wide revocation (key compromise, CA distrust, mass decommission), certctl supports bulk revocation by filter criteria. The `POST /api/v1/certificates/bulk-revoke` endpoint accepts filter parameters (profile_id, owner_id, agent_id, issuer_id) and creates individual revocation jobs for each matching certificate. Bulk revocation reuses the same 7-step single-cert flow for each certificate — no new issuer notification or audit mechanics. The operation is idempotent: revoking an already-revoked certificate is a no-op. Partial failures are tolerated — if one certificate fails to revoke (e.g., issuer unavailable), the operation continues for remaining certs and returns a summary. A single `bulk_revocation_initiated` audit event logs the operation with filter criteria, operator actor, and summary (total requested, succeeded, failed counts). Audit events for individual certificate revocations record the operator identity separately. The GUI bulk revoke button on the certificates list filters by visible selections and displays an affected-cert count modal before confirmation.

 ### 4. Automatic Renewal

@@ -1264,7 +1264,7 @@ flowchart TB
   - **Claims it** via `POST /discovered-certificates/{id}/claim` — links to existing managed cert or creates new enrollment
   - **Dismisses it** via `POST /discovered-certificates/{id}/dismiss` — removes from triage, marked as "Dismissed"
 9. **Status tracking** — `discovery_cert_claimed` and `discovery_cert_dismissed` events audit the operator's decision
-10. **Summary** — `GET /api/v1/discovery-summary` returns count of Unmanaged, Managed, and Dismissed certs (useful for compliance reporting)
+10. **Summary** — `GET /api/v1/discovery-summary` returns count of Unmanaged, Managed, and Dismissed certs (useful for inventory reporting)

 This data flow is pull-based and non-blocking. Agents discover at their own pace; the server stores results for later review. There's no pressure to claim or dismiss; operators can leave certificates in "Unmanaged" status indefinitely.

@@ -1328,11 +1328,10 @@ Captured baseline numbers are committed in `deploy/test/loadtest/README.md` once

 ## What's Next

- [Quick Start](quickstart.md) — Get certctl running locally
- [Advanced Demo](demo-advanced.md) — Issue a certificate end-to-end
- [Connector Guide](connectors.md) — Build custom connectors
- [Compliance Mapping](compliance.md) — SOC 2, PCI-DSS 4.0, and NIST SP 800-57 alignment
+- [Quick Start](../getting-started/quickstart.md) — Get certctl running locally
+- [Advanced Demo](../getting-started/advanced-demo.md) — Issue a certificate end-to-end
+- [Connector Guide](connectors/index.md) — Build custom connectors
 - [MCP Server Guide](mcp.md) — AI-native access to the API
- [OpenAPI Spec](openapi.md) — Full API reference and SDK generation
- [Testing Guide](testing-guide.md) — Test procedures and release sign-off
- [Test Environment](test-env.md) — Docker Compose test environment setup
+- [API Reference](api.md) — OpenAPI 3.1 spec and SDK generation
+- [QA Test Suite](../contributor/qa-test-suite.md) — Test procedures and release sign-off
+- [Test Environment](../contributor/test-environment.md) — Docker Compose test environment setup
@@ -225,7 +225,7 @@ camelCase form (`keyCompromise`, `cACompromise`,
 `aACompromise`) plus underscore_lower and ALL_CAPS_UNDERSCORE
 variants. An unknown reason returns an error rather than silently
 demoting to `unspecified` — operators rely on the reason for
-compliance reporting (PCI-DSS §3.6, HIPAA §164.312).
+audit reporting.

 ## Related docs

@@ -190,7 +190,7 @@ Paste into security review:
  previous cert; both outcomes are surfaced via Prometheus.
 - The minimum IAM policy is 5 actions on
  `arn:aws:acm:*:*:certificate/*`; CloudTrail captures every
-  API call for compliance audits.
+  API call for audit.

 ## ValidateOnly contract

@@ -179,7 +179,7 @@ Paste into security review:
  snapshotted previous version's bytes; both outcomes are
  surfaced via Prometheus.
 - The minimum RBAC role is 3 data-plane actions; Activity Log
-  captures every API call for compliance audits.
+  captures every API call for audit.

 ## ValidateOnly contract

@@ -23,7 +23,7 @@ Use the GlobalSign Atlas HVCA connector when:

 - You're a GlobalSign Atlas customer issuing high volumes of
  publicly trusted certificates (the "HV" in HVCA).
- You want region-pinned issuance for compliance or latency
+- You want region-pinned issuance for regulatory or latency
  reasons (EMEA / APAC / Americas regional endpoints).
 - You're prepared to manage both mTLS client certs AND
  API key/secret credentials in tandem.
@@ -202,7 +202,7 @@ The Local CA issuer signs certificates using Go's `crypto/x509` library. It supp

 **Sub-CA mode:** Loads a CA certificate and private key from disk (`CERTCTL_CA_CERT_PATH` + `CERTCTL_CA_KEY_PATH`). The CA cert is signed by an upstream CA (e.g., ADCS), so all issued certificates chain to the enterprise root trust hierarchy. Clients that already trust the enterprise root automatically trust certctl-issued certs. Supports RSA, ECDSA, and PKCS#8 key formats. If the paths are not set, falls back to self-signed mode. The loaded certificate must have `IsCA=true` and `KeyUsageCertSign`.

-**Tree mode (Rank 8 — multi-level CA hierarchy):** When `Issuer.HierarchyMode = "tree"` is set on the issuer row, the local connector reads the active CA hierarchy from the `intermediate_cas` table and assembles `IssuanceResult.ChainPEM` by walking the `parent_ca_id` ancestry from the issuing leaf CA up to the root. Tree mode is operator-managed via the admin-gated `/api/v1/issuers/{id}/intermediates` and `/api/v1/intermediates/{id}` endpoints (`POST` to create / sign children, `GET` to list / inspect, `POST .../retire` to two-phase retire). The signing path is shared with single-mode (cert is signed via `c.caCert` + `c.caSigner` from the on-disk issuing CA cert+key); only the chain bytes differ. RFC 5280 §3.2 (self-signed root validation), §4.2.1.9 (path-length tightening), and §4.2.1.10 (NameConstraints subset semantics) are enforced at the service layer fail-closed. The default is `single`, byte-identical to the pre-Rank-8 historical flow. See `docs/intermediate-ca-hierarchy.md` for the operator runbook covering 4-level FedRAMP boundary CA, 3-level financial-services policy CA, 2-level internal-PKI patterns + the migration runbook for flipping a single-mode issuer to tree.
+**Tree mode (Rank 8 — multi-level CA hierarchy):** When `Issuer.HierarchyMode = "tree"` is set on the issuer row, the local connector reads the active CA hierarchy from the `intermediate_cas` table and assembles `IssuanceResult.ChainPEM` by walking the `parent_ca_id` ancestry from the issuing leaf CA up to the root. Tree mode is operator-managed via the admin-gated `/api/v1/issuers/{id}/intermediates` and `/api/v1/intermediates/{id}` endpoints (`POST` to create / sign children, `GET` to list / inspect, `POST .../retire` to two-phase retire). The signing path is shared with single-mode (cert is signed via `c.caCert` + `c.caSigner` from the on-disk issuing CA cert+key); only the chain bytes differ. RFC 5280 §3.2 (self-signed root validation), §4.2.1.9 (path-length tightening), and §4.2.1.10 (NameConstraints subset semantics) are enforced at the service layer fail-closed. The default is `single`, byte-identical to the pre-Rank-8 historical flow. See `docs/reference/intermediate-ca-hierarchy.md` for the operator runbook covering common 4-level boundary, 3-level policy, and 2-level internal-PKI patterns + the migration runbook for flipping a single-mode issuer to tree.

 **CRL and OCSP support (M15b):** The Local CA supports DER-encoded X.509 CRL generation served unauthenticated at `GET /.well-known/pki/crl/{issuer_id}` (RFC 5280 §5, RFC 8615, `Content-Type: application/pkix-crl`) with 24-hour validity. An embedded OCSP responder at `GET /.well-known/pki/ocsp/{issuer_id}/{serial}` (RFC 6960, `Content-Type: application/ocsp-response`) returns signed OCSP responses for issued certificates (good/revoked/unknown status). Both endpoints are reachable by relying parties with no certctl API credentials, which is how standard TLS clients, browsers, and hardware appliances consume these resources. Certificates with profile TTL < 1 hour automatically skip CRL/OCSP — expiry is treated as sufficient revocation for short-lived credentials.

@@ -314,7 +314,7 @@ The connector is registered in the issuer registry under `iss-acme-staging` and

 The cert version must exist in the local store: this means the cert was issued through certctl, not imported. If `GetVersionBySerial` returns `sql.ErrNoRows`, the connector returns an actionable error pointing at the local-store requirement. Revoke-by-serial is therefore only available for ACME certs that certctl issued.

-Reason codes follow RFC 5280 §5.3.1: nil reason maps to `unspecified` (0), and the connector accepts the canonical camelCase form (`keyCompromise`, `cACompromise`, `affiliationChanged`, `superseded`, `cessationOfOperation`, `certificateHold`, `removeFromCRL`, `privilegeWithdrawn`, `aACompromise`) plus underscore_lower and ALL_CAPS_UNDERSCORE variants. An unknown reason returns an error rather than silently demoting to `unspecified` — operators rely on the reason for compliance reporting (PCI-DSS §3.6, HIPAA §164.312).
+Reason codes follow RFC 5280 §5.3.1: nil reason maps to `unspecified` (0), and the connector accepts the canonical camelCase form (`keyCompromise`, `cACompromise`, `affiliationChanged`, `superseded`, `cessationOfOperation`, `certificateHold`, `removeFromCRL`, `privilegeWithdrawn`, `aACompromise`) plus underscore_lower and ALL_CAPS_UNDERSCORE variants. An unknown reason returns an error rather than silently demoting to `unspecified` — operators rely on the reason for audit reporting.

 Audit reference: `cowork/issuer-coverage-audit-2026-05-01/RESULTS.md` Top-10 fix #7.

@@ -398,7 +398,7 @@ certctl's OpenSSL adapter `exec`s an operator-supplied script for every certific

 **When you should NOT use the OpenSSL adapter:**

- Compliance environments (PCI-DSS Level 1, FedRAMP High, HIPAA-regulated PHI handling) where shell-out attack surfaces are formally disallowed by your security policy.
+- Regulated environments where shell-out attack surfaces are formally disallowed by your security policy.
 - Multi-tenant certctl-server deployments where tenant-A's script can affect tenant-B's certificates.
 - Environments without operator review of every script line — trust-on-first-use is the wrong posture for a shell-out.
 - For these cases, switch to a Go-native issuer adapter (Vault, DigiCert, Sectigo, ACME, AWSACMPCA, GoogleCAS, EJBCA, Entrust, GlobalSign, step-ca) or commission a custom Go-native adapter for your CA (the issuer connector interface in `internal/connector/issuer/interface.go` is small — `IssueCertificate` + `RevokeCertificate` + `GetCACertPEM` + a few stubs).
@@ -478,7 +478,7 @@ See [`legacy-est-scep.md`](../protocols/scep-server.md#scep-mtls-sibling-route-p

 #### Microsoft Intune Certificate Connector dispatcher

-When a profile has `CERTCTL_SCEP_PROFILE_<NAME>_INTUNE_ENABLED=true`, certctl validates the Microsoft Intune Certificate Connector's signed-challenge JWS natively as a drop-in NDES replacement (the Intune Connector documents itself as RFC 8894-compliant and works against any RFC 8894 SCEP server). The dispatcher walks parse → JWS signature verify (RS256 + ES256, alg=none rejected) → version dispatch → time bounds with ±tolerance → audience pin → CSR ↔ claim binding → replay cache → per-device rate limit → optional V3-Pro compliance hook. The trust anchor file is reloaded on `SIGHUP` (operator rotates the on-disk PEM, then `kill -HUP <certctl-pid>`); a parse failure during reload keeps the OLD pool so a half-rotation doesn't take Intune down.
+When a profile has `CERTCTL_SCEP_PROFILE_<NAME>_INTUNE_ENABLED=true`, certctl validates the Microsoft Intune Certificate Connector's signed-challenge JWS natively as a drop-in NDES replacement (the Intune Connector documents itself as RFC 8894-conformant and works against any RFC 8894 SCEP server). The dispatcher walks parse → JWS signature verify (RS256 + ES256, alg=none rejected) → version dispatch → time bounds with ±tolerance → audience pin → CSR ↔ claim binding → replay cache → per-device rate limit → optional V3-Pro device-state hook. The trust anchor file is reloaded on `SIGHUP` (operator rotates the on-disk PEM, then `kill -HUP <certctl-pid>`); a parse failure during reload keeps the OLD pool so a half-rotation doesn't take Intune down.

 | Variable | Required | Default | Description |
 |----------|----------|---------|-------------|
@@ -493,7 +493,7 @@ See [`scep-intune.md`](../protocols/scep-intune.md) for the full deployment guid

 #### SCEP probe in network scanner

-The Network Scans GUI surface includes a one-click "Probe SCEP" form that runs a capability + posture check against any reachable SCEP server URL — `GetCACaps` + `GetCACert` (NEVER `PKCSReq`) so the probe is read-only and safe to run against production endpoints. Result fields surface advertised caps (POSTPKIOperation, SHA-256, SHA-512, AES, SCEPStandard, Renewal), CA cert subject + issuer + algorithm + days-to-expiry + chain length, and a probe duration. Results persist to `scep_probe_results` (migration `000021`) and the probe history is paginated under `GET /api/v1/network-scan/scep-probes`. Useful for pre-migration assessment ("what does the existing NDES advertise?") and compliance-posture audits.
+The Network Scans GUI surface includes a one-click "Probe SCEP" form that runs a capability + posture check against any reachable SCEP server URL — `GetCACaps` + `GetCACert` (NEVER `PKCSReq`) so the probe is read-only and safe to run against production endpoints. Result fields surface advertised caps (POSTPKIOperation, SHA-256, SHA-512, AES, SCEPStandard, Renewal), CA cert subject + issuer + algorithm + days-to-expiry + chain length, and a probe duration. Results persist to `scep_probe_results` (migration `000021`) and the probe history is paginated under `GET /api/v1/network-scan/scep-probes`. Useful for pre-migration assessment ("what does the existing NDES advertise?") and posture review.

 | Endpoint | Auth | Description |
 |----------|------|-------------|
@@ -1325,7 +1325,7 @@ certctl's SSH connector dials each target with `HostKeyCallback: ssh.InsecureIgn
 **When you should NOT use the SSH connector:**

 - Deploying to **unknown / dynamic / multi-tenant** hosts where the IP-to-hostname binding isn't operator-controlled.
- Environments with strict **regulatory MITM-resistance** requirements (PCI-DSS Level 1, FedRAMP High, etc.) — the inline-comment "out of scope" framing doesn't satisfy compliance auditors who want documented host-key verification at the connector level.
+- Environments with strict **regulatory MITM-resistance** requirements where the inline-comment "out of scope" framing doesn't satisfy reviewers who want documented host-key verification at the connector level.
 - For these cases, switch to a different connector (Kubernetes Secrets, WinCertStore, F5 with iControl REST under operator-managed cert pinning) **OR** layer a custom `SSHClient` with full `known_hosts` validation per the mitigations above.

 **V3-Pro forward path:**
@@ -1546,7 +1546,7 @@ The ARN updates in place across renewals (ACM `ImportCertificate` is upsert-styl
 - The cert key is held only in agent memory during the import call; never written to disk.
 - Every imported ACM cert is tagged with `certctl-managed-by=certctl` + `certctl-certificate-id=<mc-id>` for forensic traceability.
 - Failed imports trigger automatic rollback to the snapshotted previous cert; both outcomes are surfaced via Prometheus.
- The minimum IAM policy is 5 actions on `arn:aws:acm:*:*:certificate/*`; CloudTrail captures every API call for compliance audits.
+- The minimum IAM policy is 5 actions on `arn:aws:acm:*:*:certificate/*`; CloudTrail captures every API call for audit.

 **ValidateOnly contract.** ACM has no dry-run API for `ImportCertificate`; `ValidateOnly` returns `target.ErrValidateOnlyNotSupported` per the deploy-hardening I Phase 3 sentinel contract. Operators preview deploys via `ValidateConfig` + `aws acm describe-certificate --certificate-arn <arn>` against the current ARN.

@@ -1628,7 +1628,7 @@ Application Gateway / Front Door reference the cert by KID URI; certctl rotates
 - The cert key is held only in agent memory during the PFX wrap + import call; never written to disk.
 - Every imported Key Vault cert is tagged with `certctl-managed-by=certctl` + `certctl-certificate-id=<mc-id>` for forensic traceability.
 - Failed imports trigger automatic rollback by re-importing the snapshotted previous version's bytes; both outcomes are surfaced via Prometheus.
- The minimum RBAC role is 3 data-plane actions; Activity Log captures every API call for compliance audits.
+- The minimum RBAC role is 3 data-plane actions; Activity Log captures every API call for audit.

 **ValidateOnly contract.** Key Vault has no dry-run API; `ValidateOnly` returns `target.ErrValidateOnlyNotSupported`. Operators preview deploys via `ValidateConfig` + `az keyvault certificate show --vault-name <name> --name <cert>`.

@@ -83,10 +83,9 @@ enforced at the service layer fail-closed. The default is
 `single`, byte-identical to the pre-Rank-8 historical flow.

 See [intermediate-ca-hierarchy.md](../intermediate-ca-hierarchy.md)
-for the operator runbook covering 4-level FedRAMP boundary CA,
-3-level financial-services policy CA, 2-level internal-PKI
-patterns, and the migration runbook for flipping a single-mode
-issuer to tree.
+for the operator runbook covering 4-level boundary, 3-level policy,
+and 2-level internal-PKI patterns, and the migration runbook for
+flipping a single-mode issuer to tree.

 ## Configuration

@@ -40,9 +40,8 @@ Look elsewhere when:
  Sectigo, ACME, AWS ACM PCA, Google CAS, EJBCA, Entrust,
  GlobalSign, step-ca). Use the native adapter — narrower attack
  surface, no shell-out exposure.
- You're in a compliance environment (PCI-DSS Level 1, FedRAMP
-  High, HIPAA-regulated PHI handling) where shell-out attack
-  surfaces are formally disallowed.
+- You're in a regulated environment where shell-out attack
+  surfaces are formally disallowed by your security policy.
 - You're running multi-tenant certctl-server where tenant-A's
  script can affect tenant-B's certificates.

@@ -39,10 +39,9 @@ Look elsewhere when:
  (`InsecureIgnoreHostKey`); MITM resistance requires the
  mitigations below.
 - Your environment has strict regulatory MITM-resistance
-  requirements (PCI-DSS Level 1, FedRAMP High). The inline-comment
-  "out of scope" framing on host-key acceptance doesn't satisfy
-  auditors who want documented host-key verification at the
-  connector level.
+  requirements. The inline-comment "out of scope" framing on
+  host-key acceptance doesn't satisfy reviewers who want
+  documented host-key verification at the connector level.

 ## Configuration

@@ -298,8 +298,8 @@ Out of scope for the V2-free deploy-hardening I bundle:
 - **Multi-region deployment coordination** — orchestration of N
  data-center deploys with operator approval gates per stage.
 - **Cert-pinning verification against mobile-app pin manifests**.
- **SOC 2 evidence-report generator** — auto-export of the
-  deploy audit trail in the format SOC 2 auditors expect.
+- **Audit-evidence report generator** — auto-export of the
+  deploy audit trail in a reviewer-friendly format.
 - **Customer-paid validation matrices** — vendor-version certified
  quirks (e.g. "tested on F5 v15.1 + v17.0 + v17.5"). See
  `cowork/deploy-hardening-ii-prompt.md` for the per-vendor
@@ -10,10 +10,10 @@ The default `single`-mode flow (one operator-supplied sub-CA loaded
 from disk at boot) is unchanged and will keep working byte-for-byte
 forever. This page is for operators who need a real CA tree:

- FedRAMP boundary-CA deployments where the regulator requires
-  separation of policy and issuing authorities.
- Financial-services policy-CA deployments (one root, one policy CA
-  per business unit, one issuing CA per environment).
+- Boundary-CA deployments where you want separation of policy and
+  issuing authorities.
+- Policy-CA deployments (one root, one policy CA per business unit,
+  one issuing CA per environment).
 - OT / industrial control networks where the air-gapped root signs
  online sub-CAs that go in and out of service on a rotation.

@@ -74,12 +74,12 @@ the children first.

 ## Common deployment patterns

-### Pattern A — 4-level FedRAMP boundary CA
+### Pattern A — 4-level boundary CA

 ```mermaid
 flowchart TD
    Root["Acme Root CA<br/>path_len=3<br/>offline air-gapped"]
-    Policy["Acme Policy CA<br/>path_len=2<br/>FedRAMP-Moderate boundary"]
+    Policy["Acme Policy CA<br/>path_len=2<br/>boundary"]
    IssA["Acme Issuing A<br/>path_len=0<br/>prod workload leaves"]
    IssB["Acme Issuing B<br/>path_len=0<br/>ephemeral pod identity"]
    Root --> Policy --> IssA --> IssB
@@ -9,7 +9,7 @@
 > `internal/service/est*_test.go`, and (for the libest interop layer)
 > `deploy/test/est_e2e_test.go` under `//go:build integration`. The
 > bundle is **V2-free**; per-tenant CA isolation, Conditional-Access
-> compliance gating, and EST cert-bound usage analytics are documented
+> device-state gating, and EST cert-bound usage analytics are documented
 > as V3-Pro deferrals in [V3-Pro deferrals](#v3-pro-deferrals).

 ## Contents
@@ -710,10 +710,10 @@ These capabilities are deferred to V3-Pro (paid tier). They're not
 oversights — they're the natural follow-on bundles after v2.X.0 GA:

 - **Conditional Access / device-posture gating.** The per-profile
-  ESTService exposes a nil-default compliance-hook seam (mirrors the
-  SCEP/Intune `ComplianceCheck` pattern). V3-Pro plugs in a
+  ESTService exposes a nil-default device-state hook seam (mirrors
+  the SCEP/Intune `DeviceStateCheck` pattern). V3-Pro plugs in a
  Microsoft Graph or other posture-check callback before issuance;
-  non-compliant devices fail with a typed `est_compliance_failed`
+  failing devices fail with a typed `est_device_state_failed`
  reason.
 - **Multi-tenant CA isolation.** V2 has one trust anchor pool per
  EST profile and one issuer binding. V3-Pro ships per-tenant root
@@ -5,10 +5,10 @@
 > **Status (this document):** Phase 11 of the SCEP RFC 8894 + Intune master
 > bundle. The behavior described here is shipped on `master` and exercised
 > end-to-end by `internal/api/handler/scep_intune_e2e_test.go`. The
-> bundle is V2-free (community edition) — Conditional-Access compliance
-> gating, native Microsoft Graph integration, and per-tenant trust
-> anchors are documented under [Limitations](#limitations) as V3-Pro
-> features.
+> bundle is V2-free (community edition) — Conditional-Access
+> device-state gating, native Microsoft Graph integration, and
+> per-tenant trust anchors are documented under
+> [Limitations](#limitations) as V3-Pro features.

 ## TL;DR

@@ -101,9 +101,10 @@ PKIMessage with the documented `pkiStatus`/`failInfo` codes (per RFC
   issuing many DIFFERENT valid challenges for the same device. Default
   3 enrollments per 24h covers legitimate first-cert + recovery +
   post-wipe.
-9. **Optional compliance check** — V3-Pro plug-in seam (nil-default
-   no-op). When set, the gate calls Microsoft Graph's compliance API
-   and short-circuits non-compliant devices with FAILURE+BadRequest.
+9. **Optional device-state check** — V3-Pro plug-in seam
+   (nil-default no-op). When set, the gate calls Microsoft Graph's
+   device-compliance API and short-circuits failing devices with
+   FAILURE+BadRequest.

 A request that passes all nine gates flows to
 `processEnrollment`, which builds the issuance request, calls the
@@ -245,7 +246,7 @@ common root cause and the operator action.
 | `rate_limited`       | A specific device hitting `429`-equivalent failures              | The device exceeded `INTUNE_PER_DEVICE_RATE_LIMIT_24H` (default 3). If legitimate (post-wipe + recovery + first-cert all in 24h), bump the cap. If suspicious, this is the limiter doing its job — investigate the device. |
 | `unknown_version`    | Sudden onset of failures across the entire fleet                  | Microsoft shipped a new Connector version with a `version` claim certctl doesn't understand. Open an issue on the certctl repo with the failing claim payload (anonymized); the parser dispatcher accepts new versions in ~30 LoC. |
 | `malformed`          | Sporadic, low-volume                                              | Malformed challenge bytes — almost always a network proxy mangling the request body, or the Connector logging itself out mid-handshake. Capture a packet trace; the Connector should re-emit on the next device retry. |
-| `compliance_failed`  | V3-Pro only                                                       | The pluggable compliance check returned non-compliant. The audit-log details carries the reason string from Microsoft Graph. V2 deployments never see this counter tick.                                          |
+| `device_state_failed` | V3-Pro only                                                      | The pluggable device-state check rejected the device. The audit-log details carries the reason string from Microsoft Graph. V2 deployments never see this counter tick.                                          |

 ## Operational monitoring (SCEP Administration → Intune Monitoring tab)

@@ -327,10 +328,10 @@ V3-Pro:
  directly — the Connector already did that. V3-Pro could ship a
  Graph client that pulls device-compliance state in addition to
  the challenge claim.
- **Conditional Access compliance gating.** The dispatcher exposes a
-  nil-default `ComplianceCheck` hook. V3-Pro plugs in a Microsoft
-  Graph compliance lookup before issuance; non-compliant devices
-  fail with a typed `compliance_failed` failInfo.
+- **Conditional Access device-state gating.** The dispatcher exposes
+  a nil-default `DeviceStateCheck` hook. V3-Pro plugs in a Microsoft
+  Graph device-compliance lookup before issuance; failing devices
+  exit with a typed `device_state_failed` failInfo.
 - **Per-tenant trust anchors.** V2 has one trust anchor pool per
  SCEP profile; V3-Pro could support per-AAD-tenant anchor scoping
  for MSPs running shared certctl deployments across customers.
@@ -3,7 +3,7 @@
 > Last reviewed: 2026-05-05

 > Deploy-hardening II master bundle deliverable. The procurement-team
-> headline doc — SOC 2 / PCI auditors paste this into evidence packs.
+> headline doc — reviewers paste this into vendor-evaluation packs.
 > Per frozen decision 0.14: a (connector × vendor-version) cell is
 > "verified" only when ALL apply: ≥1 happy-path e2e passes against
 > the real sidecar; ≥1 specific-quirk test for that version passes;