Authorized behaviour
Digital assets should perform only intended functions within declared operating conditions and authority limits.
IAF Standards Programme
IAF Digital Systems Integrity
Cyber resilience, secure development, update integrity and privacy
An evidence-based framework for maintaining trustworthy digital behaviour across connected vehicles, software, services and the complete automotive lifecycle.
First Edition · Draft for Technical Review · 13 September 2026
Read the Full Working Draft
26 clauses · Annexes A-F · 32 verification cases
At a glance
What Digital Systems Integrity Is Designed to Protect
The standard brings vehicle electronics, software, connected services, artificial intelligence, update infrastructure and personal-data processing into one assessment boundary. Its aim is to prevent compromise where practicable, contain it when prevention fails and support recovery without unacceptable physical or privacy harm.
Resilience and recovery
Failures and hostile actions should be contained, observable and recoverable through tested technical controls.
Responsible data use
Personal data, permissions, retention and transfer should remain controlled throughout the product lifecycle.
Evidence-based conformity
Claims depend on identifiable scope, reproducible verification and records connected to the assessed baseline.
Connected responsibility
Who the Framework Supports
Responsibilities follow control over the product or service. Partial-scope results remain linked to their integration assumptions, while the system integrator retains responsibility for the complete declared scope.
01Vehicle and platform manufacturers
02Electronic, component and software suppliers
03Cloud, mobile and connected-service operators
04Mobility providers and fleet operators
05Engineering, diagnostics and service organizations
06Verification, assessment and decision teams
Framework structure
The 26 Clauses in Six Clear Groups
The full document contains detailed technical requirements. This table groups the clauses to show how the framework moves from scope and risk to verification, transparency and continuing review.
| Clauses | Group | What it covers |
|---|---|---|
| 01-04 | Foundation and Scope | Intended outcomes, mandatory rules, terminology, declared scope and integrity profiles. |
| 05-09 | Governance, Risk and Trust | Accountability, threat analysis, digital assets, architecture, identity and cryptographic trust. |
| 10-15 | Secure Delivery and Data | Secure development, build provenance, suppliers, OTA updates, cloud operations and privacy. |
| 16-20 | Resilience and Emerging Systems | Recovery, vulnerability handling, monitoring, artificial intelligence and automated mobility. |
| 21-23 | Lifecycle and Verification | Production, diagnostics, repair, ownership transfer, end-of-life support and technical assessment. |
| 24-26 | Decision and Transparency | Conformity decisions, material change, integrity passports and technology evolution. |
Need the technical detail? The working draft includes the complete DSI requirements, the required evidence register, test procedures and binding acceptance parameters.
Assurance depth
Three Integrity Profiles
Every profile applies the relevant baseline requirements. Higher profiles increase the independence and depth of assurance according to the authority, connectivity and possible consequence of compromise.
Baseline verification
For scopes with demonstrated boundaries and no credible route to essential-function interference, high-impact privacy harm or fleet propagation.
Independent integration assessment
For connected services, remote functions, valuable credentials or sensitive personal data where compromise can cause material harm.
Organizationally independent assurance
For essential-function influence, remote actuation, automated-driving authority, release-signing roots or fleet-wide privileged operations.
Key ideas
What Readers Should Take Away
A valid signature is not proof that an action is safe
Authentication and provenance matter, but authorized content must still remain within validated behaviour and operating limits.
Dependencies remain inside the integrity boundary
Suppliers, cloud services and shared control planes cannot be excluded when they can affect the declared product or service.
Material changes require reassessment
Changes to software, models, services, authority, trust roots or dependencies can invalidate earlier evidence and decisions.
Missing mandatory evidence prevents a conformant decision
Scope, applicability, test results, findings and approval authority must remain connected to the assessed baseline.
Using the document
From Declared Scope to an Evidence-Based Decision
Development status: This proposed First Edition is published for technical review, industry consultation and pilot assessment. It does not itself authorize conformity claims.
01Declare the scope, lifecycle and integrity profile
02Map assets, threats, trust boundaries and dependencies
03Run applicable verification cases against declared limits
04Record evidence, findings, decisions and material changes
Continue with the full technical document
Review all 26 clauses, Annexes A-F, the 32 verification cases and the acceptance parameters in the published PDF.