ETSI EN 304 223 and UK AI Cyber Security Code of Practice Guide: 13 Principles, Provisions and Evidence

Most organisations building or deploying AI have no agreed baseline for what "secure enough" means for a model, its data, its prompts and the permissions it holds on other systems. The UK government's AI Cyber Security Code of Practice, published by DSIT on 31 January 2025, set out 13 principles for that baseline. ETSI then turned the same text into ETSI TS 104 223 (V1.1.1, April 2025) and, after a European vote, into the European Standard ETSI EN 304 223 V2.1.1 (December 2025), announced by ETSI on 14 January 2026. This guide explains who the documents apply to, how the 13 principles and their provisions are structured, which provisions matter most for identity and non-human identities, and how to build evidence that would stand up to a customer or auditor. For the wider UK policy picture, see the UK AI Regulation Guide.

Key takeaways

• One text, three documents. The UK Code, ETSI TS 104 223 and ETSI EN 304 223 share the same 13 principles across five lifecycle phases; the EN is the current, formally approved version.
• Voluntary, but increasingly asked for. Neither the Code nor the EN is a law. They become binding when a customer contract, procurement framework or internal policy cites them.
• Roles drive obligations. Every provision is assigned to Developers, System Operators or Data Custodians, so the first job is deciding which roles your organisation holds for each AI system.
• Permissions are a named requirement. Provision 5.1.2-6 (Code 2.6) requires the permissions an AI system holds on other systems to be limited to what it needs and risk assessed, which makes agent credentials and service accounts in scope.
• Evidence is mostly logs and records. Asset inventories, audit trails of models, datasets and prompts, change logs for system prompts and logs of system and user actions are what an assessor will ask to see.

What it is and who it applies to

The Code of Practice for the Cyber Security of AI is a voluntary code from the Department for Science, Innovation and Technology (DSIT), written with the NCSC and positioned as an addendum to the UK Software Code of Practice. The government's collection page says DSIT would submit the Code and its implementation guide to ETSI so they could become TS 104 223 and TR 104 128, and that the UK Code and guide would be updated to mirror the ETSI documents. ETSI's Technical Committee Securing Artificial Intelligence (TC SAI) published TS 104 223 V1.1.1 in April 2025; the document history in EN 304 223 records that it then went through the ETSI European Norm approval process and was published as EN 304 223 V2.1.1, dated December 2025.

Scope: both the Code and the EN cover AI systems, including those built on deep neural networks such as generative AI, and treat AI security as a subset of cyber security. Systems built and tested purely for research that will never be deployed are out of scope. The Code adds that vendors who only sell models or components and play no part in developing or deploying them are more likely covered by the Software Code of Practice and the Cyber Governance Code (see the UK Cyber Governance Code of Practice Guide).

Stakeholder roles: the documents define five roles. One organisation often holds several at once.

• Developers: anyone who creates or adapts an AI model or system, including open-source models.
• System Operators: organisations that embed or deploy an AI model or system in their infrastructure, including providers of contracted deployment services. An enterprise that wires a hosted LLM into a customer service agent is a System Operator.
• Data Custodians: those who control data permissions, data integrity and data-use policies for a model or system.
• End-users: employees and consumers who use the system.
• Affected entities: people and technologies affected by AI outputs without interacting with the system directly.

Structure and key requirements

The EN keeps the Code's principle order and places each principle in a clause under one of five lifecycle phases. Provisions are numbered clause-then-item, so Code provision 2.6 becomes EN provision 5.1.2-6 and Code provision 12.1 becomes 5.4.2-1. The EN follows ETSI drafting rules: "shall" is a requirement, "should" a recommendation and "may" a permission. Some provisions are marked as applying to specific roles only.

Prompts are treated as security artefacts alongside models and datasets, and residual risk is accepted explicitly (Code 3.4): the requirement is to monitor against a stated risk appetite.

Identity and NHI requirements

Neither the Code nor the EN uses the words "agent", "service account" or "non-human identity", and they contain no agent-specific provisions. Identity requirements still sit inside several provisions, and they bite hardest on agentic systems that hold credentials to other systems.

• AI system permissions (5.1.2-6, Code 2.6): permissions on other systems or data sources must be limited to what the functionality needs and risk assessed. In practice this covers the OAuth grants, API keys, database users and cloud roles an assistant or agent uses. TR 104 128 suggests listing every integration with its permissions and reviewing the potential harm with a security specialist. The PocketOS database deletion shows the failure this provision targets: a coding agent found an account-scoped API token created for an unrelated task and used it to delete a production database.
• Access control frameworks (5.2.2-1, Code 6.1): review access control for APIs, models, data and training or processing pipelines. That includes who can change model weights, push a new system prompt or modify a retrieval index.
• API protection (5.2.2-2, Code 6.2): Developers offering external APIs apply controls such as rate limits against model extraction and rapid poisoning. Per-client credentials are a precondition for meaningful rate limits.
• Separated, least-privilege environments (5.2.2-3, Code 6.3): development and tuning environments are separated and follow least privilege. Pipeline service accounts that can read production data and write production models break this.
• Authenticated assets (Code 5.2): AI assets are tracked, authenticated and version controlled; with published hashes for model components (Code 8.1.2) this is the asset identity half of the picture. See the Model Signing and OpenSSF Model Signing Guide.
• Attributable logging (5.4.2-1, Code 12.1): System Operators log system and user actions. For agents this means logging which identity the agent acted as and on whose behalf, not just the prompt and the answer.

For the identity design itself, see the Agentic AI Identity Guide and the AI Agent Authorisation Guide.

Implementation steps

1. Build the AI inventory first. List every AI model and system you develop or operate, with owner, role held (Developer, System Operator, Data Custodian), hosting, data sources and integrations. This satisfies the start of Principle 5 and drives everything else. The AI Register and AI Inventory Template gives a starting format.
2. Assign roles per system. For each entry record which roles you hold. A bank fine-tuning an open model and deploying it internally is Developer, System Operator and Data Custodian; a firm using a hosted copilot is System Operator only. Filter the provision list by role.
3. Run a gap assessment against the EN provisions. Use the EN numbering (5.x.y-n) as the control ID in your GRC tool so evidence maps cleanly if customers ask for EN 304 223 alignment. Mark each provision met, partly met or not met, with an owner.
4. Fix permissions and credentials early. Inventory the non-human identities each AI system uses, remove standing broad tokens, scope them to the functionality, and record the risk assessment required by 5.1.2-6. This is usually the highest risk-reduction per hour.
5. Put prompts, models and datasets under change control. Store system prompts in version control, require review for changes, and log deployments (5.1.2-3 and 5.2.4-3). Record source URL and retrieval date for public training data (Code 8.2.1).
6. Threat model and test. Threat model each system against data poisoning, model inversion, membership inference and prompt injection, then test before deployment with independent testers where the risk justifies it (Principle 9). See the AI Red Teaming Guide.
7. Turn on logging and monitoring. Log system and user actions, tool calls and identity used, and route them to the SOC with analytics for drift, anomalies and abuse (Principle 12).
8. Pilot, then expand. Pilot the full set on one high-risk system for one quarter, adjust templates, then roll out by risk tier. If a control breaks a production workflow (for example a rate limit or a removed permission), roll back that single control, record the exception with an expiry date and a compensating control, and retest.

Small and large organisations

A small firm using hosted models as a System Operator can usually meet its share with a short inventory, scoped API keys held in a secrets manager, vendor due diligence (Code 2.7 and 3.3), logging and an incident plan. A large Developer needs the full set, including MLOps versioning, published hashes and a vulnerability disclosure policy. Where you buy rather than build, put the Developer provisions into supplier contracts; the NCSC explicitly suggests buyers use the documents to inform procurement (see the AI Procurement Checklist).

Evidence and assessment

There is no certification scheme attached to the Code, and the NCSC describes the ETSI documents as something developers can use to show prospects and partners that they follow the framework. Assessment today means customer questionnaires, second-party audits or internal assurance. Build evidence that a reviewer can sample.

Metrics that show it is working

• Inventory coverage: percentage of AI systems found by discovery (SSO logs, egress to AI APIs, cloud AI services) that are in the register.
• Permission assessment coverage: percentage of AI integrations with a current 5.1.2-6 risk assessment.
• Over-privileged AI credentials: number of AI-held tokens with admin or account-wide scope, trending down.
• Tested before release: percentage of new or majorly updated models tested before deployment (Code 11.2 treats major updates as a new model).
• Log completeness: percentage of AI systems whose tool calls and identities reach the SIEM.

Mapping to other frameworks

EN 304 223 cites ISO/IEC 27001, the EU AI Act, NIST, OWASP and MITRE ATLAS as informative references. The table below is our own mapping.

For a wider crosswalk across NIST AI RMF, ISO/IEC 42001, OWASP and the EU AI Act, see the AI Security Frameworks Crosswalk Guide and the ISO/IEC 42001 Guide. The EN is a security baseline, not an AI management system: ISO/IEC 42001 covers governance, and the EN supplies technical requirements that sit under it.

Common pitfalls

• Treating hosted AI as out of scope. Buying a model does not remove your System Operator provisions.
• Broad standing tokens for convenience. Agents given a personal access token or an account-wide API key fail 5.1.2-6 on day one, and the impact appears when the agent misreads its task, as in the PocketOS case.
• Prompts edited in production. System prompts changed through an admin console with no history leave no audit trail for 5.2.4-3 and no way to roll back a harmful change.
• Logging the conversation but not the action. Chat transcripts without tool calls, target systems and identities used cannot support an investigation under Principle 12.
• Citing the wrong document. Contracts that still cite only the January 2025 UK Code or TS 104 223 should be updated to name EN 304 223 V2.1.1 and to say which roles the supplier holds.

Practitioner checklist

• Record, per AI system, whether you are Developer, System Operator and/or Data Custodian.
• Load the EN 304 223 provisions into your control library using the EN numbering.
• Maintain one AI asset register with dependencies, versions and hashes.
• Complete a 5.1.2-6 permission risk assessment for every integration and replace account-wide tokens with scoped credentials.
• Put system prompts and configuration under version control with reviewed changes.
• Threat model each system and re-run it after configuration or model changes.
• Test before deployment and after every major model update.
• Log system and user actions, tool calls and identities to the SIEM, with alert rules.
• Write AI-specific incident, recovery and disposal procedures, and test restoring a known good state.
• Name EN 304 223 and the expected roles in AI supplier contracts and questionnaires.

Standards and references

• ETSI: EN 304 223 V2.1.1 Securing Artificial Intelligence (SAI); Baseline Cyber Security Requirements for AI Models and Systems
• DSIT: Code of Practice for the Cyber Security of AI
• DSIT: AI Cyber Security Code of Practice (collection and implementation guide)
• ETSI: TR 104 128 V1.1.1 Guide to Cyber Security for AI Models and Systems
• ETSI: ETSI releases world-leading standard for securing AI
• NCSC: New ETSI standard protects AI systems from evolving cyber threats
• MITRE ATLAS: AI Agent Tool Invocation
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: UK AI Regulation Guide · AI Security Frameworks Crosswalk Guide · Agentic AI Identity Guide · EU AI Act Compliance Guide. This guide summarises the UK AI Cyber Security Code of Practice and ETSI EN 304 223 and is not legal advice.