Most AI security guidance looks at the model and the application, while the GPU servers, accelerators, firmware and schedulers that train and serve those models are left to generic data centre controls. ETSI TS 104 033 V1.1.1, published by ETSI Technical Committee Securing Artificial Intelligence (TC SAI) in May 2026 and announced on 2 June 2026, is the first ETSI specification that sets security requirements for the AI computing platform itself. This guide explains what the specification covers, how its requirements and security services are organised, how it links to ETSI EN 304 223 and EN 303 645, and how platform teams, cloud and GPU service operators, and buyers of AI infrastructure can turn it into an implementation plan. It is written for infrastructure architects, platform security engineers and assurance teams who need to show that AI workloads run on a platform that protects models and data at rest, in transit and in use.
Source note: clause content and version details are from ETSI TS 104 033 V1.1.1 (2026-05) as published on etsi.org, and the release date from the ETSI press release; implementation phases and metrics are NHI Mgmt Group guidance. Confirm against the official text before relying on it.
Key takeaways
- It is a platform specification, not a model standard. TS 104 033 defines security requirements, security functions, components and service interfaces for platforms that host AI applications, mainly in data centre and edge environments.
- Seven requirement areas and seven security services. Clause 5.1 sets requirements for identity and access, integrity, data protection, audit, response and resilience; clause 5.2 defines services such as accelerator resource isolation, training recovery, inference attack detection and a Model BoM service.
- Threats come from GR SAI 009. The specification adopts the threat tables of ETSI GR SAI 009 (2023) without change, so read both: one lists the threats, the other the requirements that answer them.
- Two normative baseline mappings. Annex A maps the platform to ETSI EN 303 645 and Annex F maps it to ETSI EN 304 223, where the platform plays the System Operator role.
- Hardware roots of trust are central. Secure boot, hardware unique keys, hardware mediated execution environments and attestation underpin most of the requirements, so procurement decisions about accelerators and servers matter as much as software configuration.
What TS 104 033 is and where it sits
The full title is "Securing Artificial Intelligence (SAI); Security requirements for an Artificial Intelligence Computing Platform" (reference DTS/SAI-006). It is a Technical Specification, which in ETSI terms is a consensus document from a technical committee, not a European Norm adopted through national standards bodies. It is voluntary unless a contract, a regulator or a certification scheme makes it mandatory. ETSI positions it as a security baseline that can support compliance with regulations including the EU AI Act, but it is not a harmonised standard under that Act.
The scope states that the specification defines the security functions, components and interfaces of an AI computing platform, is aimed at platform designers, and applies mainly to data centre and edge environments. Mobile and embedded devices may adapt the framework. It defines an AI computing platform simply as a computing platform intended to host AI applications.
The ETSI SAI document family
| Document | Type | Role relative to TS 104 033 |
|---|---|---|
| ETSI GR SAI 009 V1.1.1 (2023-02) | Group Report | The original AI computing platform security framework; its Tables 1 and 2 are the threat model TS 104 033 adopts |
| ETSI EN 304 223 | European Norm | Baseline cyber security requirements for AI models and systems across five lifecycle phases; mapped in normative Annex F |
| ETSI EN 303 645 | European Norm | Consumer IoT baseline; reused as a general product security baseline in normative Annex A |
| ETSI TS 104 224 | Technical Specification | Explicability and transparency of AI processing; the only normative reference in clause 2.1 |
| ETSI TR 104 048 | Technical Report | Data supply chain security; clause 4 says the platform should respect its recommendations |
See the ETSI EN 304 223 and UK AI Cyber Security Code of Practice Guide for the model and system layer that sits above the platform.
The platform model: three layers and the assets they hold
Clause 4 and Annex B describe the platform in three layers. Requirements are easier to assign to owners when you map your own stack against them.
- Hardware layer: hosts and AI accelerators (GPUs, NPUs), with hardware based root of trust, trusted boot modules, hardware unique keys (HUKs) for host and accelerator identity that cannot be modified after factory set-up, hardware mediated execution environments (HMEEs), abnormality detection, resource isolation and secure communication modules (Annex B.2).
- Basic software layer: operating system, chip SDK and virtualisation for virtual machines and containers, with integrity protection, trust measurement and system abnormality detection (Annex B.3).
- AI application enabling layer: AI frameworks, application SDK and management, with security management, inference attack detection, encryption and decryption, training recovery, log protection and the Model BoM module (Annex B.4).
Components connect through internal reference points N1 to N15, and the platform exposes service interfaces S1 to S7 to AI applications: log protection, encrypt and decrypt, inference detection, security management, isolated resource allocation, recovery and Model BoM. The assets in scope follow GR SAI 009: models, training data sets, testing data sets, inference data and training scripts, each exposed to theft from storage or memory, tampering, fake insertion, residual recovery after poor erasure, deletion and physical destruction.
Clause 5.1: the security requirements
TS 104 033 does not give requirements separate identifiers, so teams normally use clause numbers as IDs in their control registers. Strength follows ETSI modal verbs: "shall" is mandatory, "should" is recommended. Check the verb in the published text for each line before you record it as mandatory.
| Clause | Area | What the platform must or should do |
|---|---|---|
| 5.1.2 | Identity management and access control | Disable external physical debug interfaces such as JTAG after manufacture; control access to physical interfaces; prohibit remote access to root privileged accounts; allow only identified, authenticated and authorised parties to use resources |
| 5.1.3.1 | Integrity of start-up data | Support secure boot, with Trusted Computing Group style measurement and remote attestation using a TPM, HSM or secure enclave |
| 5.1.3.2 | Integrity of AI model data | Verify model integrity before inference |
| 5.1.4.1 | Data in transit | Protect data against unauthorised exposure and allow only authorised endpoints; TLS 1.3 (RFC 8446) is given as an example |
| 5.1.4.2 | Data at rest | Back up and recover configuration and recovery data |
| 5.1.5 | Secure audit | Log AI asset events; make logs tamper evident; restrict log access |
| 5.1.6 | Secure response | Detect and control abnormal network traffic; provide intrusion detection; detect operating system anomalies in key files, processes, containers and privileged accounts |
| 5.1.7 | Resilience | Monitor accelerator health such as temperature and power and apply coping mechanisms such as degradation or workload reallocation; provide a safe mode that recovers to a predefined normal state |
Clause 5.2: the seven security services
Clause 5.2 turns the requirements into services the platform offers to the AI workloads it hosts. These are where TS 104 033 goes beyond a generic server hardening baseline.
- 5.2.2 AI asset protection in transmission and storage: multi-tenant encryption in which each tenant manages its own keys, cannot reach other tenants' content and should not be able to infer their existence; hardware bound decryption so that only designated accelerators can decrypt assets; cryptographic integrity checks before assets are used.
- 5.2.3 AI asset protection in processing: isolated execution environments for AI assets, cryptographic protection or isolation (or both) of the link between CPU and accelerator, resistance to denial of service and anomaly detection tuned to model activity. This is where confidential computing applies. See the Confidential AI and GPU Enclaves Guide.
- 5.2.4 AI accelerator resource isolation: exclusive allocation of compute and memory per tenant with quotas, preferably hardware based isolation, controlled access for authorised stakeholders, segregated traffic for remote access, and isolation of prompts, data and reasoning against injection between workloads. See the GPU and AI Cluster Multi Tenancy Security guide.
- 5.2.5 Training procedure recovery: detect abnormalities at chip, node and network level, restore training state, resume automatically and reduce the recovery point objective for long training runs.
- 5.2.6 Inference attack detection: model agnostic detection of malicious queries and adversarial samples, with dynamic switching of detection models, low overhead and multimodal input support, covering energy and latency attacks, adversarial samples and model stealing.
- 5.2.7 AI related log storage and transfer: secure storage and transfer of logs, including to trusted third parties, integrity verification, alerts on integrity failure, and backup and recovery of logs.
- 5.2.8 Model BoM service: interfaces through which stakeholders submit model information, platform managed keys derived and protected in hardware, and generation of a proof manifest of integrity and authenticity. The manifest format is out of scope; CycloneDX v1.7 is cited as an informative reference. See the AI Supply Chain and AI-BOM Guide.
Annex E is candid about Model BoM risk: a detailed bill of materials helps attackers study the attack surface and can be manipulated to mislead the people who rely on it. Its advice is to choose items for suitability rather than comprehensiveness, split items into public and private classes, protect private items with access control and hardware or cryptographic confidentiality, and integrity protect the BoM itself.
Threat to requirement mapping
Because the threat model sits in GR SAI 009, a mapping table is the quickest way to show an assessor that each threat has an answer. The ATLAS techniques below are examples of how the same threats are named in MITRE ATLAS.
| GR SAI 009 threat | TS 104 033 answer | Related reference |
|---|---|---|
| Physical interface manipulation (USB, JTAG) | 5.1.2 disable debug interfaces, control physical access | NIST SP 800-53 AC-6 |
| Component tampering (firmware, software) | 5.1.3.1 secure boot, measurement, attestation | NIST SP 800-53 SI-7, SR-11 |
| Lateral movement through shared VM, container or PCI device | 5.2.4 accelerator resource isolation, 5.2.3 isolated execution | NIST SP 800-53 SC-39 |
| Model theft from storage or memory | 5.2.2 hardware bound decryption, 5.2.3 HMEE and protected CPU to accelerator link | ATLAS AML.T0024 Exfiltration via AI Inference API (query based theft), SC-28 |
| Stored or in-memory model tampering, fake model insertion | 5.1.3.2 integrity check before inference, 5.2.8 Model BoM proof | ATLAS AML.T0010 AI Supply Chain Compromise |
| Dataset tampering and fake dataset insertion | 5.2.2 integrity verification, data supply chain per TR 104 048 | NIST CSF 2.0 PR.DS-01 |
| Inference data eavesdropping, spoofing | 5.1.4.1 authorised endpoints, TLS 1.3 | SC-8, PR.DS-02 |
| DoS and resource exhaustion | 5.2.3 DoS resistance, 5.2.6 energy and latency attack detection | ATLAS AML.T0029 Denial of AI Service |
| Adversarial inputs at inference | 5.2.6 inference attack detection | ATLAS AML.T0043 Craft Adversarial Data |
| Clock tampering to hide activity from audit | 5.1.5 tamper evident logs, 5.2.7 log integrity | NIST SP 800-53 AU-9 |
Baseline mappings: EN 303 645 and EN 304 223
Annex A maps EN 303 645 clauses 5.1 to 5.13 and clause 6 to the platform. Provision 5.1 on universal default passwords is marked not applicable, secure storage (5.4) is met through TS 104 033 clause 5.1.4.2, and secure communication (5.5) through clause 5.1.4.1. Annex F maps EN 304 223 and treats the AI computing platform as a System Operator.
| EN 304 223 phase | TS 104 033 clauses that support it |
|---|---|
| 5.1 Secure design | 5.1.6, 5.1.7, 5.2.5 and 5.2.6 for withstanding attacks, failures and unexpected inputs; 5.1.5, 5.2.7 and 5.2.8 for audit trails |
| 5.2 Secure development | 5.2.8 Model BoM, 5.2.5 for disaster recovery, 5.2.2 and 5.2.3 for sensitive data, 5.1.2 and 5.2.4 for access control and isolation |
| 5.3 Secure deployment | The platform reinforces development choices and keeps the system operating as designed |
| 5.4 Secure maintenance | 5.1.5 logging of system and user actions; 5.2.6 detection of sudden or gradual behaviour change |
| 5.5 Secure end of life | 5.2.8 Model BoM for tracing models |
For EU AI Act work, the platform evidence most often feeds Article 15 on accuracy, robustness and cybersecurity. See the EU AI Act Article 15 Guide. Treat TS 104 033 as supporting evidence, not as a presumption of conformity.
Where identity fits
Clause 5.1.2 is short but carries a lot of identity work. Every training job, inference server, scheduler, storage mount and telemetry agent on an AI cluster authenticates as a non-human identity, and the platform's HUKs give hosts and accelerators a hardware identity that attestation builds on. In practice that means: no shared root or service accounts across nodes, workload identities issued per job rather than long-lived keys baked into container images, tokens to model registries and object storage scoped to one tenant, and attestation results checked before keys are released to a workload. See the AI Infrastructure Workload Identity Guide and the Hardware key attestation guide. Exposed AI tooling credentials remain a real failure: the Hugging Face Spaces breach involved unauthorised access to secrets stored for AI applications.
Implementing TS 104 033: a phased approach
- Scope and gap assessment (weeks 1 to 4): list every cluster, edge node and managed AI service in scope, map your stack to the three layers, and score each clause 5.1 and 5.2 item as met, partly met or not met, using clause numbers as IDs. Record the "shall" or "should" verb for each.
- Hardware and boot foundation: enforce UEFI Secure Boot, collect measured boot logs, stand up a remote attestation service and confirm debug interfaces and unused physical ports are disabled. Pilot on one rack first and keep a documented rollback (signed known-good firmware and boot policy) before enforcing fleet wide.
- Access and identity: remove remote root login, move administrators to just-in-time privileged access, replace static node and job credentials with short-lived workload identities, and separate the management plane network.
- Tenant isolation and asset protection: decide between whole-accelerator allocation, hardware partitioning and time slicing for each tenant class; introduce per-tenant keys in a KMS or HSM and, where workloads are sensitive, confidential computing with attestation-gated key release. Test isolation with red team exercises before onboarding external tenants.
- Integrity and Model BoM: sign models and datasets at the point of registration, verify at load time, and generate a proof manifest per model version. Run verification in report-only mode for one release cycle, then block unsigned artefacts.
- Detection, logging and recovery: route AI asset events, scheduler actions and privileged sessions to tamper evident storage; deploy inference attack detection on externally exposed endpoints; checkpoint training jobs and test automatic resumption after injected node failures.
- Evidence pack: assemble a clause-by-clause statement of applicability with the Annex A and Annex F mappings, so customers and auditors can trace each claim.
Decision guidance by organisation type
| You are | Priority clauses | Trade-offs |
|---|---|---|
| Public GPU cloud or AI hosting provider | 5.2.2, 5.2.3, 5.2.4, 5.2.7 | Hardware isolation and confidential computing cost utilisation and performance; offer them as tiers and say clearly which tier meets which clause |
| Enterprise running private AI clusters | 5.1.2, 5.1.3, 5.1.5, 5.2.5 | Single tenant clusters can rely more on access control than on hardware partitioning, but internal business units may still need separation |
| Edge AI operator | 5.1.2 (physical interfaces), 5.1.3.1, 5.1.7 safe mode | Physical access risk is higher; attestation and remote recovery matter more than inference attack detection |
| Buyer of AI infrastructure | Use clause 5 as a questionnaire | Ask for the statement of applicability, attestation evidence and isolation test results, not a yes or no answer |
Small teams should start with the clauses that remove whole classes of risk cheaply: debug interfaces off, no remote root, secure boot on, model signing, and tamper evident logs. Large providers will need the full service set because tenants will ask for it.
Detection and measurement
- Attestation coverage: percentage of hosts and accelerators that pass remote attestation before receiving workloads (target 100 percent for multi-tenant pools).
- Signed artefact rate: percentage of model and dataset loads verified against a signature or Model BoM proof.
- Static credential count: number of long-lived keys or passwords used by nodes, jobs and agents, trending to zero.
- Isolation exceptions: number of tenants sharing accelerators without hardware partitioning, with risk acceptance recorded.
- Training recovery time: median time to resume a training job after a node or network failure, and the lost work (RPO) per incident.
- Log integrity alerts: count and time to triage of integrity failures in the AI log store.
Common failure patterns
- Treating the model layer as the whole problem: teams adopt EN 304 223 for models and leave the cluster on generic hardening, so model files and weights in memory have no hardware protection.
- Isolation by scheduler policy only: time sliced GPUs shared between tenants without memory clearing or hardware partitioning, which is exactly the lateral movement threat GR SAI 009 lists.
- Secure boot enabled but never attested: measurement logs are produced and nobody checks them, so a tampered node still receives workloads and keys.
- Over-detailed public Model BoM: publishing every component and version, which Annex E warns gives attackers a map.
- Static secrets on shared AI tooling: registry and storage tokens in notebooks and images, as in the DeepSeek database exposure, where an open database leaked chat logs and API secrets.
- Claiming compliance without evidence: TS 104 033 has no certification scheme of its own, so a vendor statement without a clause-level applicability statement proves little.
Framework mapping
| TS 104 033 area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| 5.1.2 Identity and access | AC-6 Least Privilege | PR.AA-01 |
| 5.1.3 Integrity | SI-7 Software, Firmware, and Information Integrity; SR-11 Component Authenticity | PR.PS-01 |
| 5.1.4 and 5.2.2 Data protection | SC-8, SC-28 | PR.DS-01, PR.DS-02 |
| 5.1.5 and 5.2.7 Audit and logs | AU-9 Protection of Audit Information | DE.CM-09 |
| 5.1.6 Secure response | IR-4 Incident Handling | DE.AE-02 |
| 5.1.7 and 5.2.5 Resilience and recovery | CP-10 System Recovery and Reconstitution | RS.MA-01 |
| 5.2.3 and 5.2.4 Isolation | SC-39 Process Isolation | PR.PS-01 |
Practitioner checklist
- Download TS 104 033 V1.1.1 and GR SAI 009 and build a register with clause numbers as requirement IDs and the modal verb for each.
- Map your AI stack to the hardware, basic software and application enabling layers and assign an owner per clause.
- Disable JTAG and unused physical interfaces, and remove remote root access on every node and management controller.
- Enforce secure boot and gate workload and key release on successful remote attestation.
- Choose and document an accelerator isolation model per tenant class, with risk acceptance where hardware isolation is not used.
- Sign models and datasets, verify before inference, and generate a Model BoM proof with public and private item classes.
- Replace static node and job credentials with short-lived workload identities scoped per tenant.
- Send AI asset events to tamper evident log storage and alert on integrity failures.
- Test training recovery and safe mode at least twice a year with injected failures.
- Publish a statement of applicability with the Annex A and Annex F mappings for customers and auditors.
Standards and references
- ETSI: TS 104 033 V1.1.1 Securing Artificial Intelligence (SAI); Security requirements for an Artificial Intelligence Computing Platform
- ETSI: GR SAI 009 V1.1.1 Artificial Intelligence Computing Platform Security Framework
- ETSI: ETSI releases Standard on Securing AI Computing Platforms
- MITRE: ATLAS Adversarial Threat Landscape for AI Systems
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- IETF: RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
Related NHI Mgmt Group resources: ETSI EN 304 223 and UK AI Cyber Security Code of Practice Guide · GPU and AI Cluster Multi Tenancy Security · Confidential AI and GPU Enclaves Guide · AI Infrastructure Workload Identity Guide · ETSI EN 303 645 Consumer IoT Guide. This guide summarises ETSI TS 104 033 and is not legal advice.