K05 assurance architecture
Identity, firmware, and management planes remain trustworthy
Direct answer
Privileged identities, workload identities, signing keys, BMCs, firmware, update systems, model artifacts, and management networks are separately protected and continuously evidenced.
Evidence boundary. These records describe architecture, control relationships, test requirements, and legal-source status. They do not certify a facility, authorize a mission, prove deployment, or replace current facility-specific engineering and legal review.
Claim
Privileged identities, workload identities, signing keys, BMCs, firmware, update systems, model artifacts, and management networks are separately protected and continuously evidenced.
Argument
A compromised management plane can bypass controls in the host workload and persist below ordinary endpoint visibility.
Evidence requirements
- asset and firmware inventory
- secure-boot and attestation evidence
- key status
- BMC isolation tests
- signed update provenance
- privileged-session logs
- SBOM and vulnerability status
Assurance defeaters
- unknown firmware
- default credentials
- shared administrative identity
- unverified update
- attestation failure
- unmonitored BMC egress
Hazards
- ring-minus-three persistence
- cluster-wide destructive control
- supply-chain compromise
- identity replay
Recovery objectives
- revoke affected identities
- quarantine management segment
- restore signed firmware
- re-attest before service return
Site-tailoring questions
- hardware vendor
- BMC implementation
- HSM and key custody
- maintenance contractor
- air-gapped update process
Sources and record
NIST SP 800-207 — Zero Trust Architecture · NIST SP 800-218 Secure Software Development Framework Version 1.1 · NIST SP 800-82 Revision 3 — Guide to Operational Technology Security