Join our Newsletter — 33% off our NHI Course
Home› Glossary› Architecture & Implementation› Automotive Grade Linux
Architecture & Implementation

Automotive Grade Linux

← Back to Glossary
By NHI Mgmt Group Updated October 29, 2026 Domain: Architecture & Implementation

Automotive Grade Linux is an open source Linux distribution and reference platform for in-vehicle software. It provides a common base for infotainment and related automotive applications, with vehicle-specific components added by manufacturers and suppliers on top of the core operating system.

What Automotive Grade Linux Is Used For

Automotive Grade Linux is designed as a shared software foundation for in-vehicle systems, especially infotainment and adjacent automotive application layers. Its value comes from standardising the core platform so manufacturers and suppliers can focus on vehicle-specific features above it.

That common base can reduce duplication across programmes, but it also means security choices made in the platform layer can propagate widely across models, suppliers and trims. In practice, the distribution becomes part of the trust boundary for everything built on top of it.

Why a Shared In-Vehicle Linux Base Matters

A common automotive operating system helps teams align on interfaces, package management, runtime behaviour and integration patterns. That can improve portability and speed up development, but it also creates a larger shared dependency if the base image, update path or configuration posture is weak.

For security teams, the important point is that a platform used by many downstream applications should be treated as a foundational component, not just a convenience layer. A defect in the base OS, its services or its integration defaults can affect multiple suppliers and vehicle functions at once.

Because the platform is open source and broadly reused, organisations should pay attention to provenance, hardening and change control across the full stack, from the Linux base through to vendor-added modules and vehicle integration code.

Security Considerations for Automotive Platforms

In-vehicle software faces a different threat model from ordinary enterprise Linux deployments. The same platform that powers user-facing infotainment may also sit close to interfaces that can influence diagnostics, telematics, media subsystems or other connected services, so segmentation and privilege boundaries matter.

Security issues often emerge when a common platform is extended with third-party components, long-lived integrations or inconsistent hardening between suppliers. NIST Cybersecurity Framework 2.0 is a useful lens for organising governance, protection, detection and recovery around a shared platform like this.

Supply-chain integrity is also central because the deployed system depends on source code, build outputs, packages and vendor overlays staying trustworthy from development through production. That is why platform teams often pair platform governance with SLSA to strengthen build provenance and artifact integrity, and with NIST SP 800-53 Rev 5 Security and Privacy Controls to anchor control selection around access control, authentication, integrity and configuration management.

How Teams Should Evaluate and Govern It

Organisations adopting Automotive Grade Linux should treat it as a governed platform decision rather than a one-time engineering choice. That means understanding which vehicle programmes use it, which suppliers modify it, which services run on it and which update mechanisms are responsible for maintaining it.

Teams should also distinguish between the common base and the vehicle-specific additions layered on top. The base distribution may be shared, but the actual risk profile depends on what is enabled, what is exposed and how each OEM or supplier constrains the system in deployment.

For platform owners, the practical test is whether the shared foundation can be patched, monitored and audited consistently across the fleet. If not, the convenience of commonality can turn into concentration risk.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, SLSA and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0GV.OC-01 — Organizational ContextAGL is a shared vehicle software platform that needs ownership and context.
PR.DS-01 — Data-at-rest is protectedIn-vehicle software on AGL can store sensitive operational and user data.
PR.PS-04 — Software is maintained through vulnerability and patch managementA shared Linux base depends on disciplined patching and controlled maintenance.
Recommendation — Define platform ownership, scope and dependencies before standardising AGL across programmes. Protect stored data on AGL systems with encryption and access restrictions. Track and remediate vulnerabilities in the AGL base image and packaged components.
SLSASupply-chain Levels for Software ArtifactsAGL deployments rely on trusted build and artifact provenance across suppliers.
Recommendation — Verify provenance for AGL builds and downstream artifacts before deployment.
CIS Controls v8CIS-16 — Application Software SecurityAGL is a software platform whose security depends on hardened development and release practices.
Recommendation — Apply secure development and release safeguards to the AGL platform and vendor extensions.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org