I85PREP
⌘ K
TEE Engineer License study materials
TEE Engineer License study resources

TEE Engineer License: TEE Standards, Governance, and Compliance

TEE Engineer License · Work through your exam, one topic at a time.

All guide sections

TEE Standards, Governance, and Compliance

This domain tests the standards landscape and how certification and governance constrain TEE claims. Expect questions about which document defines what, and how a certificate maps to a product configuration.

Standards bodies and documents

  • GlobalPlatform publishes the TEE System Architecture, TEE Internal Core API, TEE Client API, TEE Management Framework, and protection profiles used in Common Criteria evaluations.
  • IETF RATS (RFC 9334) defines attestation roles and architecture; EAT (RFC 9397) defines a token format. TCG defines TPM 2.0 and DICE; NIST SP 800-193 covers platform firmware resiliency and recovery.
  • PSA Certified defines a root of trust and three assurance levels; its crypto and attestation APIs are widely used on Arm microcontrollers. The Confidential Computing Consortium publishes common terminology and open-source projects.
  • Common Criteria evaluates a target of evaluation against a protection profile; FIPS 140-3 and ISO/IEC 19790 validate cryptographic modules. SESIP is a lighter IoT evaluation scheme.

Governance

  • Certification is configuration-specific: the evaluated version, patch level, and options matter. A vendor's EAL4+ claim without the security target and scope is not evidence for your deployment.
  • Vulnerability handling is part of the standard: CVE assignment, coordinated disclosure, TCB recovery through microcode or TCB updates, and revocation of attestation keys.
  • Regulatory context: GDPR data-protection principles, DORA operational resilience for financial entities, and sector rules such as PCI DSS do not certify a TEE but shape what you must document.

Worked example

A payments team wants to claim a certified TEE. They map the product to a Common Criteria protection profile, select EAL4+ with ALC_FLR.2 (flaw remediation) and AVA_VAN.3, and define the security target: TA, TEE OS, and boot chain, with the REE excluded. The lab evaluates that exact build. The certificate does not cover a later TA version or debug-enabled devices, so the team adds configuration control and a re-evaluation trigger. Reasoning: the certificate's scope and assumptions must match the deployed configuration.

Traps

  • Treating a standard as an implementation.
  • Quoting an assurance level without the protection profile and scope.
  • Assuming a certificate covers future patches.
  • Confusing FIPS 140-3 module validation with TEE isolation.