If your team signs models and containers for a high-risk AI system on the EU market, your signing records become compliance evidence for the EU AI Act. The Act, formally Regulation (EU) 2024/1689, is the European Union’s risk-based law for artificial intelligence.
The high-risk rules require providers to document every released version and protect it against tampering. Publicly trusted code-signing certificates now last at most 460 days, and each signature has to stay verifiable long after its certificate expires.
Key takeaways
- Code-signing teams meet their share of the EU AI Act with protected keys, deploy-time verification, signed release manifests, and timestamped retention. Each high-risk artifact you ship then stays probably the unaltered version you documented and tested for the full 10-year documentation period.
- Stand-alone high-risk systems face obligations from December 2027, and AI embedded in regulated products follows in August 2028.
- Ask signing vendors to show that exported records can be verified without their platform. Signing every training checkpoint adds cost with little audit value.
The EU AI Act phases in through August 2028
The Commission’s implementation timeline shows the EU AI Act phasing in from February 2025 to August 2028. The Digital Omnibus on AI (Regulation (EU) 2026/1744), in force since July 27, 2026, set those high-risk dates at December 2, 2027, for Annex III systems and August 2, 2028, for AI built into Annex I products. National authorities and the Commission’s AI Office began enforcing the prohibitions, general-purpose AI rules, transparency rules, and AI literacy duties on August 2, 2026.
Table 1. EU AI Act obligations by category
| Category | Examples | Core obligations | Applies from |
| Prohibited practices | Social scoring and untargeted facial scraping | Banned | February 2, 2025, with two added bans from December 2, 2026 |
| General-purpose AI models | Foundation models | Documentation, copyright policy, training-content summary, and systemic-risk cybersecurity | August 2, 2025 |
| Transparency (Article 50) | Chatbots, synthetic media, and text | Disclose AI interaction and mark synthetic output in machine-readable form | August 2, 2026, or December 2, 2026, for generators already marketed |
| High-risk, Annex III | Hiring, credit scoring, education, and critical infrastructure | Risk management, data governance, logging, documentation, human oversight, accuracy, and cybersecurity | December 2, 2027 |
| High-risk, Annex I | AI in machinery, medical devices, and toys | The same requirements, assessed through the product’s conformity route | August 2, 2028 |
Your role decides your signing duties
The EU AI Act covers providers and deployers in the Union and those elsewhere whose system output is used there, under Article 2. In 2025, Eurostat counted 55% of large EU enterprises using AI, each one a deployer of its systems. Each role carries different signing work:
- Provider: Develops an AI system or model and places it on the market under its own name. Every must-have signing control applies to its high-risk systems.
- Deployer: Uses an AI system under its authority. Article 26 covers operation and monitoring, and checking the provider’s signatures shows you run the documented version.
- Deployer turned provider: A deployer that rebrands or substantially modifies a high-risk system becomes its provider under Article 25(1).
The Act leaves out military or national security uses, research-only AI, pre-market testing, and purely personal use. An Annex III system that performs only a narrow procedural or preparatory task, without profiling people, can also fall outside high-risk under Article 6(3). The provider must document that assessment.
Code signing supplies integrity and version evidence
Article 15(5) requires high-risk systems to resist attempts by unauthorized third parties to alter their use, outputs, or performance, including model poisoning through tampered pre-trained components. In a release pipeline, that means applying code signing to each model file and container and refusing to load or deploy anything whose signature fails.
Annex IV requires technical documentation to record software versions, cybersecurity measures, and lifecycle changes, and Article 18 requires providers to keep it on file for 10 years once the system is placed on the market. AVX Code Signing audit logs, for example, record each signing event’s time, timestamp use, and exact certificate and key.
Your compliance and data science teams own risk classification, accuracy testing, and the Article 43 conformity assessment. Signing records supply their integrity and version evidence.
Articles 17 and 50 add quality management and content-marking duties.
Table 2. EU AI Act provisions mapped to signing controls
| Provision | What it asks | Signing control | Evidence | Priority |
| Article 17 | Quality management | Protected keys | Approval records | Must-have |
| Article 15(5) | Resist tampering, including model poisoning | Deploy-time verification | Signature bundles and verification logs | Must-have |
| Annex IV 1(c), 2(h), 6 | Record versions, security measures, and changes | Signed release manifests | Manifest signatures and digests | Must-have |
| Article 18 | Keep documentation for 10 years | Timestamped retention | Timestamp tokens and certificate chains | Must-have |
| Article 25(4) | Written terms with suppliers | Signing terms in supplier contracts | Contract clauses | Should-have |
| Article 50(2) | Mark generated content, for generative systems | Signed content credentials alongside watermarks | Content credentials | Should-have |
| Articles 12 and 19 | Event logs kept for at least six months | Seal log batches with hashes or signatures | Sealed digests | Nice-to-have |
Installable software and connected devices also fall under the Cyber Resilience Act. Under its Article 12, conformity shown in the product’s EU declaration covers the AI Act’s cybersecurity duties.
Table 3. Related instruments that shape signing evidence
| Instrument | Scope | Legal status | What it means for signing teams |
| Cyber Resilience Act | Products with digital elements | Binding | Protects programs against unauthorized modification. |
| Harmonized standards | Technical standards for the Act | Voluntary | Grant presumption of conformity once cited in the Official Journal. The AI cybersecurity specification, prEN 18282, was still a draft in July 2026 |
| Code of Practice on AI-generated content | Marking and labeling of AI-generated content | Voluntary | Guides machine-readable marking. Recital 133 lists cryptographic provenance methods among the suitable techniques |
A 10-year record outlives about eight certificates
In this hypothetical, a high-risk model reaches the EU market on December 2, 2027, and each biweekly release signs four artifacts: its data manifest, weights, container, and documentation bundle.
At 460 days per certificate, every certificate behind that record expires years before the record leaves scope.
Table 4. Worked example calculations
| Calculation | Input | Result |
| Certificate lifetimes within retention | 3,653 days ÷ 460 days | 7.9 |
| Signatures to keep verifiable | 104 × 10 years | 1,040 |
A trusted timestamp, such as an RFC 3161 token or a transparency-log entry captured at signing time, proves a signature existed while its certificate was valid. Version 1.1.1 of the OpenSSF model_signing tool signs model directories with Sigstore, keys, certificates, or PKCS#11-backed keys.
A trusted timestamp, such as an RFC 3161 token or a transparency-log entry captured at signing time, proves a signature existed while its certificate was valid.
The tool’s certificate mode has no timestamp option, and its verifier checks the chain as of the certificate’s start date, so a certificate-mode signature keeps verifying after expiry with no record of signing time. Sigstore mode records each signature in a transparency log. In certificate mode, add a separate RFC 3161 timestamp.
Prioritize must-have controls and test vendor claims
Each control answers one must-have provision and follows standard code-signing best practices:
- Protected keys: Keep signing keys in Hardware Security Modules (HSMs), grant signing rights by role, and require approval for production releases.
- Deploy-time verification: Verify signatures at the deploy gate and at model load, including models from outside suppliers.
- Signed release manifests: Sign one manifest per release that ties each version number to its artifact digests.
- Timestamped retention: Add a trusted timestamp to every signature and archive certificate chains with revocation data for 10 years.
Some controls can wait
Per-output signing belongs to generative systems with content-marking duties. Sign only the training checkpoints you ship or build on. Post-quantum model signatures are futureproofing work, and crypto-agility in key policies prepares the signing setup for them.
Before you rely on a vendor’s records, ask:
- Do exported signing records verify with standard tools, without the vendor’s platform?
- Which Federal Information Processing Standard (FIPS) 140 validation covers the HSMs holding your keys?
- Does every signature get an RFC 3161 timestamp from an authority you choose?
- Can the tool sign model files and container images?
- Can you export 10 years of audit records?
AVX Code Signing holds keys and audit trails
Point model_signing at the AVX Code Signing PKCS#11 provider, and model directories get the same HSM-held keys and audit records as every other artifact.
A private PKI lets you set lifetimes for internal-only signing certificates outside the 460-day public limit. For systems that include AI agents, Agent Identity Security maps agent posture to frameworks, including the EU AI Act.
AVX Code Signing, part of the AVX Platform, maps to the must-have controls this way:
- Protected keys: Keys are generated and stored in FIPS 140-2 Level 3 HSMs, in the cloud or on-premise, and a policy engine enforces role-based access and approvals.
- Deploy-time verification: Your deploy pipeline checks signatures with standard verifiers such as SignTool or Cosign.
- Signed release manifests: Developers sign from native tools, through the API, or inside continuous integration and delivery (CI/CD) pipelines. The product documentation covers Cosign and OpenSSL, and both sign manifest files.
- Timestamped retention: The policy engine applies secure timestamping, and audit records log who signed each file and with which certificate and key.
Teams with few signers can assemble these controls from Sigstore, model_signing, and a cloud key service. The open-source route fits teams that can own policy and retention work.
Start your signing record with AppViewX
Starting now puts a run of signed, timestamped releases on record well before the high-risk rules take effect.
- Use AVX Code Signing to discover and inventory every key and certificate that signs AI artifacts. Manage each one as a non-human identity.
- Turn on timestamping and add signature checks to the deploy gate before December 2, 2027.
- Set a 10-year retention rule for signing records and test that a 2027 signature still verifies after its certificate expires.Ask model and component suppliers to sign what they ship and write that requirement into their contracts.
AVX Code Signing logs every signing event with its certificate, key, and timestamp, the record step 3 asks you to keep.
Disclaimer:
Treat this guide as general information and confirm legal questions with counsel. Sources were checked on October 15, 2026.
Frequently asked questions
Is code signing required by the EU AI Act?
The EU AI Act sets outcomes and lets each provider pick the technical measures. High-risk systems must withstand tampering, including model poisoning, and their documentation must show which version shipped and how it was secured. Timestamped signatures on models, containers, and release manifests cover both duties.
What are the fines under the EU AI Act?
Article 99 caps fines at €35 million or 7% of worldwide annual turnover for prohibited practices, €15 million or 3% for breaching operator duties, and €7.5 million or 1% for misleading information to authorities. Small and medium-sized enterprises and start-ups face the lower figure.
Does the EU AI Act apply to companies outside the EU?
Yes. Any provider placing AI systems or general-purpose AI models on the EU market falls under the Act, wherever it is based, as do operators abroad whose AI output is used in the Union. Before offering a high-risk system there, a provider based elsewhere must appoint an authorized representative inside the Union by written mandate under Article 22.
Sources
- EUR-Lex, Regulation (EU) 2024/1689 (Artificial Intelligence Act), July 12, 2024, https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
- European Commission, Timeline for the Implementation of the EU AI Act, accessed October 15, 2026, https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
- EUR-Lex, Regulation (EU) 2026/1744 (Digital Omnibus on AI), July 24, 2026, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601744
- European Commission, AI Act Explorer, July 27, 2026, https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer
- Eurostat, Use of artificial intelligence in enterprises, December 2025, https://ec.europa.eu/eurostat/statistics-explained/index.php/Use_of_artificial_intelligence_in_enterprises
- EUR-Lex, Regulation (EU) 2024/2847 (Cyber Resilience Act), November 20, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
- European Commission, Safer and more secure digital products, September 11, 2026, https://commission.europa.eu/news-and-media/news/safer-and-more-secure-digital-products-2026-09-11_en
- CA/Browser Forum, Ballot CSC-31: Maximum Validity Reduction, November 17, 2025, https://cabforum.org/2025/11/17/ballot-csc-31-maximum-validity-reduction/
- Sigstore and OpenSSF, sigstore/model-transparency, accessed October 15, 2026, https://github.com/sigstore/model-transparency
- Sigstore, Taming the Wild West of ML: Practical Model Signing with Sigstore, April 4, 2025, https://blog.sigstore.dev/model-transparency-v1.0/
- AppViewX, The Importance of Code Signing Best Practices in the Software Development Lifecycle, March 19, 2025, https://www.appviewx.com/blogs/the-importance-of-code-signing-best-practices-in-the-software-development-lifecycle/
- AppViewX, Code Signing Certificates Drop to 460 Days in 2026: What to Do About it, March 4, 2026, https://www.appviewx.com/blogs/460-day-code-signing-certificate-2026/
- IBM, AI-powered adversaries and the enterprise risk challenge: Preparing for the new reality, July 29, 2026, https://www.ibm.com/think/x-force/2026-cost-of-a-data-breach-ai-adversaries-enterprise-risk
- AppViewX, Post-Quantum Cryptography Readiness, accessed October 15, 2026, https://www.appviewx.com/solutions/crypto-agility-and-post-quantum-cryptography-readiness/
- AppViewX, Code Signing, accessed October 15, 2026, https://www.appviewx.com/products/code-signing/
- AppViewX, The AVX Platform, accessed October 15, 2026, https://www.appviewx.com/avx-platform/
- AppViewX, Integrating SIGN using Native Tools, accessed October 15, 2026, https://docs.appviewx.com/2026.2.0/oxy_ex/integrating_sign_using_native_tools.html
- AppViewX, PKI, accessed October 15, 2026, https://www.appviewx.com/products/pki-software/
- AppViewX, Agent Identity Security, accessed October 15, 2026, https://www.appviewx.com/products/ai-agent-identity-security-software/
- AppViewX, What is Non-Human Identity? June 8, 2026, https://www.appviewx.com/blogs/what-is-non-human-identity/
- AppViewX, What is Code Signing? accessed October 21, 2026, https://www.appviewx.com/education-center/what-is-code-signing/
- AppViewX, What are CSP and PKCS#11? accessed October 21, 2026, https://www.appviewx.com/education-center/what-are-csp-and-pkcs11/
- AppViewX, What are Hardware Security Modules (HSM)? accessed October 21, 2026, https://www.appviewx.com/education-center/what-are-hardware-security-modules-hsm/
- AppViewX, Private CA vs Public CA: When to Use, November 1, 2025, https://www.appviewx.com/blogs/private-ca-vs-public-ca/
- AppViewX, Talk to an Expert, accessed October 21, 2026, https://www.appviewx.com/talk-to-an-expert/
- European Commission, AI Act Article 22: Authorised representatives of providers of high-risk AI systems, accessed October 21, 2026, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-22
- DIN, DIN EN 18282 (draft, prEN 18282:2026), Cybersecurity specifications for AI systems, May 15, 2026, https://www.din.de/en/wdc-beuth:din21:402183586
Tags
About the Author
