prEN 18282 — AI cybersecurity (draft harmonised standard)

prEN 18282 is the draft harmonised standard developed by CEN/CENELEC JTC 21 for AI system cybersecurity. It operationalises primarily EU AI Act Art. 15(5): resilience against malicious exploitation of the system — data/model poisoning, adversarial examples (evasion), model confidentiality attacks, and access control failures.

Draft status — no presumption until OJEU citation

prEN 18282 is a confidential harmonised draft from CEN-CENELEC JTC 21. Its full text is not public. Once adopted as a definitive EN and cited in the Official Journal of the EU, it will confer presumption of conformity with Art. 15. Until then, applying its guidance is good technical practice without presumption effect. AI Act mandatory deadlines for Annex III have been postponed to 2 December 2027.

IP — why clause ids are semantic

The text of prEN 18282 is confidential (paid standard). The identifiers in the engine are semantic (cyber.*) and anchored in the public, binding text of Art. 15 of Reg. EU 2024/1689, not in the draft’s clause numbers.

---

Three layers not to confuse

prEN 18282 covers per-system AI-specific cybersecurity (Art. 15(5): malicious threats specific to the model). It is distinct from two other layers:

Layer	Scope	Reference standard
Organisational ISMS	Information security management of the organisation	ISO/IEC 27001 / ENS (QMS line)
Formal robustness (non-malicious)	Unintentional model perturbations: noise, distribution shift	ISO/IEC 24029-2 / prEN 18229-2 (Art. 15(4))
Per-system AI cybersecurity	Malicious exploitation of the model: poisoning, evasion, extraction, confidentiality	prEN 18282 (Art. 15(5))

The engine governs the third layer. The organisational ISMS lives in the QMS (hamazazpigarrena). Formal robustness (ISO 24029-2) is a future roadmap item.

---

What prEN 18282 covers

prEN 18282 requires the provider of a high-risk AI system to:

1. Model the threats specific to AI cybersecurity: data and model-weight poisoning, adversarial example evasion, confidentiality attacks (model extraction, model inversion, membership inference), and API/tool access control failures.
2. Protect the integrity of the artefact (code, weights, training dataset) against unauthorised modification.
3. Protect the confidentiality of the model and training data against extraction and inference attacks.
4. Implement access control with least-privilege, especially relevant for agentic systems.
5. Evaluate the residual cybersecurity risk after controls.
6. Monitor security incidents and threats post-market.
7. Document the process in a signed cybersecurity file.

---

Clause catalogue

The file crates/froga-core/resources/standards/pren-18282-clauses.yaml declares the modelled clauses.

Threat modelling (Art. 15(5))

Clause	Short title	satisfied_by
cyber.threat_modeling	Complete estimation of declared risks, including the cyber-specific threat register when declared	criterion: risk_estimation

The risk_estimation criterion verifies that every risk declared in the AssuranceProgram has likelihood and impact assigned. The clause is COVERED vacuously (if no cyber threats are declared, there is nothing to verify) — an honest state the engine documents explicitly.

Artefact integrity (Art. 15(5): data/model poisoning)

Clause	Short title	satisfied_by
cyber.data_model_integrity	Artefact, data and weights integrity/authenticity: anti data/model poisoning	measures_citing: true

This clause is covered only if there is a signed measure that cites it and whose control passes (e.g. an artefact integrity verification in the pipeline). The signed bundle alone does not cover this clause — that role belongs to cyber.security_file.

Adversarial resilience (Art. 15(5): adversarial examples)

Clause	Short title	satisfied_by
cyber.adversarial_robustness	Resilience against adversarial examples / model evasion	measures_citing: true

Honest gap — the SDK does not measure adversarial robustness yet

The measurement SDK (venturalitica-sdk) does not yet include adversarial robustness tests. Without a citing measure, this clause emits GAP for every system. Adversarial robustness (Art. 15(5)) is distinct from formal statistical robustness (Art. 15(4), ISO 24029-2): they are not interchangeable.

Access control (Art. 15(5))

Clause	Short title	satisfied_by
cyber.access_control	Least-privilege and access control at the API / tool-invocation level	measures_citing: true

Honest gap — agentic least-privilege not yet measured

No demo scenario measures the least-privilege principle in agentic systems. Without a citing measure, this clause is a GAP. This is particularly relevant for systems that invoke external tools or APIs.

Model confidentiality (Art. 15(5))

Clause	Short title	satisfied_by
cyber.confidentiality	Model confidentiality protection: anti extraction, inversion and membership inference	measures_citing: true

Honest gap — no sufficient declarative proxy yet

There is no honest declarative proxy for model confidentiality without a specific measure. Without a citing measure, this clause is a GAP.

Residual, monitoring and file

Clause	Short title	satisfied_by
cyber.residual_evaluation	Evaluation of the residual cybersecurity risk after controls	measures_citing: true
cyber.monitoring	Post-market monitoring of cybersecurity incidents/threats	measures_citing: true, evidence: monitoring_plan
cyber.security_file	Signed cybersecurity file: measures, test results and versioned attack surface	evidence: signed_bundle

---

Current coverage state

🟡 Partial — The engine covers threat modelling, artefact integrity, residual risk, and the security file. Adversarial robustness, access control and confidentiality are honest gaps until the SDK implements the corresponding measurements.

Coverage summary by threat family:

Family	Clause	Typical state
Threat modelling	cyber.threat_modeling	COVERED (if risks have likelihood+impact)
Artefact integrity	cyber.data_model_integrity	COVERED if integrity measure cites it; GAP if not
Adversarial robustness	cyber.adversarial_robustness	GAP (SDK not yet measuring)
Access control	cyber.access_control	GAP (not yet measured)
Confidentiality	cyber.confidentiality	GAP (not yet measured)
Cyber residual	cyber.residual_evaluation	COVERED if a measure cites the clause (cyber residual treated)
Monitoring	cyber.monitoring	COVERED if citing monitoring plan exists
Security file	cyber.security_file	COVERED (signed bundle is the file)

---

How to use froga conformance with prEN 18282

# Evaluate conformance against prEN 18282 from the signed bundle
froga conformance --standard eu/pren-18282@2026

# With history per RDD iteration
froga conformance --standard eu/pren-18282@2026 --history

# Export to .froga/conformance/
froga conformance --standard eu/pren-18282@2026 --out

The report emits COVERED / PARTIAL / GAP per clause, grouped by cybersecurity cycle phase.

---

Relation to other standards

• EU AI Act Art. 15 — the legal obligation prEN 18282 operationalises; see EU AI Act.
• ISO/IEC 27001 — the organisational ISMS (not per-system); lives in the QMS, not in the engine.
• ISO/IEC 24029-2 / prEN 18229-2 — formal robustness (non-malicious perturbation, Art. 15(4)); future roadmap item in the engine.
• DORA — in financial entities, per-system ICT threat resilience also covers DORA Art. 9 obligations. See DORA.
• ISO 23894 — the underlying risk management process; risk_estimation is the primary criterion for threat modelling. See ISO 23894.