What a Linux Safety Certification Actually Covers

If you build vehicle software on Linux, a supplier will at some point hand you a claim that sounds decisive: this platform is certified. The engineer who has to integrate it then finds the claim carries almost no information on its own. A Linux safety certification is bounded by a configuration, a set of assumptions, a hardware list and an assessor. This article explains where those bounds come from, what changed in 2024, and what to ask before accepting such a claim into your own safety case.

Why the kernel cannot be qualified

Functional safety standards assume a particular kind of software. A classic safety component is written against a complete requirements specification, each requirement traced to a design element, to code and to a test, with structural coverage evidence at the end. That is workable for tens of thousands of lines written by one team for one purpose. The Linux kernel is not that: tens of millions of lines, contributed by thousands of people who never wrote a requirements specification for the automotive context, changing on a nine-week cadence.

An earlier article here, Safety-Critical Linux: What Certifying It Actually Takes, sets out how a safety argument is assembled around Linux. This goes a level below it: by what defined mechanism does pre-existing software become admissible in an ISO 26262 argument at all, and what does the resulting certificate bound?

Before 2024 there was no route designed for this, which is why a Linux safety certification was so hard to scope. The two normally reached for are both in ISO 26262-8:2018, the supporting-processes part: qualification of software components, and the proven-in-use argument. Qualification expects the component’s functional behaviour, resource usage and behaviour under failure and overload to be specified and tested, which is impractical across the number of interfaces a kernel exposes. Proven in use expects field evidence about an unchanged element, which does not fit a codebase that takes fixes continuously.

What ISO/PAS 8926:2024 adds to a Linux safety certification

ISO/PAS 8926:2024 is titled Road vehicles — Functional safety — Use of pre-existing software architectural elements. Published on 29 January 2024, 19 pages, from ISO/TC 22/SC 32, the subcommittee that produces ISO 26262. It is a Publicly Available Specification rather than an International Standard, so it is a published route to a Linux safety certification rather than an obligation, and whether a programme uses it is a matter for its safety plan and its assessor.

It defines a term for the thing you are trying to bring in. A pre-existing software architectural element, abbreviated PSAE, is software that already exists — commercial off the shelf or custom — that was not built to order and was not developed to conform with the ISO 26262:2018 series. The Linux kernel meets that definition, as do the C library and a vendor BSP’s driver set. Meeting it is a starting condition, not a verdict: an element becomes safety-related only when software safety requirements are allocated to it, or when its failures could violate one.

One of the two elements the specification illustrates is an operating system. Its general clause describes an OS hosting safety-related applications and names the properties such an element can carry: correct execution with partitioning to achieve freedom from interference, and a defined strategy for fault handling. The other illustration is a safety-related device driver. That first one tells you what a Linux safety certification is about — not that the kernel is correct, but that this configuration provides partitioning and fault handling adequate to the requirements allocated to it.

That sentence is easy to read too generously. Naming partitioning as a property of an operating system is not the same as a stock kernel supplying it. Freedom from interference has to be argued for the specific resources the safety function uses, and the mechanisms are mostly not kernel defaults: memory and device isolation through the MMU and the IOMMU, a hypervisor or a separate safety island, CPU affinity and cpuset reservation, interrupt affinity, explicit device assignment, and watchdogs with defined restart domains and safe states. Each of those has to be configured deliberately and then shown to hold. The residual paths are where the argument is usually lost rather than won: a DMA-capable peripheral reaching memory it should not, cache and memory-bandwidth contention between a safety task and an infotainment workload, a shared clock or reset domain, or a driver shared across the partition boundary. Enabling an isolation feature is the start of the argument, not the argument.

The examination of a pre-existing element covers, among other things:

• which of the element’s functions and properties correspond to the safety requirements allocated to it;
• whether its implementation and interfaces fit the static and dynamic design of the target architecture;
• whether the target has enough hardware and software resources once it is integrated;
• whether unused functionality can be shown not to interfere, or excluded — the specification names build-process configuration settings as the way this is done;
• whether unintended behaviour is absent, or the risk it introduces is low enough.

The fourth changes daily work. A kernel configuration here is not a build preference; it is the evidence for what was built into the image and what was left out. Note the limit: not compiled in is not the same as absent from the running system. Anything set to m still ships and can be loaded, and options pulled in by select arrive without being asked for.

Classification, complexity and evidence

The mechanism ISO/PAS 8926 adds on top of ISO 26262-8, and the one that decides the shape of a Linux safety certification, is a classification step. It decides whether software qualification under ISO 26262-8:2018, Clause 12 applies to the element, or whether specific safety activities are tailored under ISO 26262-2:2018, 6.4.5.1 and 6.4.5.2, and planned under 6.4.6.7. Confirmation measures under 6.4.9 may apply to the classification and impact analysis themselves. Those cross-references are cited by number inside the specification.

Two considerations drive the classification. The first is that uncertainty about the process used to develop the element may increase the likelihood of systematic faults. The second is that the element’s complexity can make systematic faults harder to find. Complexity is then evaluated with selected measures, and the specification allows numerical methods such as cyclomatic complexity or a count of lines, as well as qualitative methods.

Applied to the kernel, this determines what a Linux safety certification can claim. Complexity is an explicit acceptance input, so the way to make the argument tractable is to reduce the element rather than defend it: the smallest configuration that still supports the allocated requirements. A line count is only an input, and not the one that dominates — configuration choices, concurrency, and the number of interfaces exposed through system calls, ioctls and sysfs matter more to a Linux platform than any single number. The practical work is configuration reduction, interface analysis and exclusion of unused subsystems, not kernel code review.

The specification also defines provenance — the origins, custody and ownership of the software and its data — which for a kernel arriving as a vendor BSP branch on a stable series on mainline means which tree, which tag, which patches, and who applied them. The route has an entry condition too: it assumes a software safety requirements specification, a safety analysis report and organisation-level functional-safety processes already exist. A BSP team cannot start here.

One limit, stated plainly: the classification criteria, the class boundary, the suitability evaluation and both annexes are in the paid text and were not read for this article.

What changed, and when

The last row indicates where the standard is heading, and should be read carefully rather than optimistically. A part moving to “to be revised” tells you the committee intends a new edition. It does not tell you what that edition will say, and no publication date was found. Planning a programme around a future Part 8 means planning around something that does not exist yet.

Reading a Linux safety certification claim

The clearest public example of a scoped claim is Red Hat’s. In a press release dated 20 May 2025, Red Hat states that Red Hat In-Vehicle Operating System achieved functional safety certification as a Safety Element out of Context against ISO 26262 Edition 2, 2018, at ASIL-B, assessed by exida. The same release says customers will receive a Safety Guidance document containing Assumptions of Use, and that qualified hardware platforms will be rolled out on a cadence within the scope of the certification, with Renesas stating that the first certification will be on the R-Car S4. Those were forward-looking statements in May 2025. This article did not read the exida certificate or any assessment report and found no later dated statement, so which platforms are in scope today is not established here.

Almost all of that is scope: a named product rather than “Linux”, a named assessor, a named standard and level, and a hardware list that grows over time, so the certificate covers the silicon on that list and not the silicon you happen to have. That gives a repeatable test. For any Linux safety certification claim, ask these six questions, and ask for the artefact in the third column rather than accepting the answer in prose.

Two things a Linux safety certification does not do are worth stating. It does not transfer an integrity level to your item: an out-of-context element is assessed against an assumed ASIL, while the level your item needs comes from your own hazard analysis. And ISO 26262 does not require third-party certification at all. What it requires is a functional safety assessment and confirmation measures, so a supplier delivering a safety case with an independent assessment and no certificate can be entirely conformant.

Three claims are also used interchangeably when they are not the same, and only one of them is a Linux safety certification. Certified means an assessment happened and a certificate names a scope. Certifiable means a package exists to support an assessment you must still arrange. A safety package is available means documentation exists and no assessment has been stated. All three can be legitimate; only the first carries an assessor’s name.

A certificate does not freeze the baseline

The awkward part of a Linux safety certification is that the certified thing keeps moving. Security fixes arrive, the vendor rebases, the toolchain is updated, a board revision changes. None of that is prohibited, and none of it is free: each change needs an impact analysis against the certified scope, the Assumptions of Use and the evidence set, and the depth of re-verification that follows depends on the change and on the safety plan. ISO/PAS 8926 carries a clause on changes to the element’s design, whose content sits in the paid text.

The practical consequence is that a Linux safety certification is a baseline under control, not a baseline frozen. A programme that cannot say which patches it has taken since the assessed release, and what each one touched, has lost the thread of its own argument regardless of what the certificate says. This is the same problem as provenance, seen from the maintenance end.

What ELISA does, and what it does not

The Linux Foundation’s ELISA project — Enabling Linux In Safety Applications — is where much of the shared groundwork happens. Its site lists eight working groups: Aerospace, Automotive, Linux Features for Safety-Critical Systems, Medical Devices, Open-Source Engineering Process, Safety Architecture, Systems, and Tools. It publishes tooling openly, including BASIL and ks-nav.

Its position on certification is worth stating because it is often assumed to be otherwise. In the write-up of the ELISA Workshop held at Canonical’s London office from 9 to 11 June 2026, published on 27 August 2026, the project records that its Ask Me Anything session clarified that ELISA does not certify Linux and does not guarantee the safety of a complete product. Its role is to identify gaps and develop approaches organisations apply in their own certification contexts, so an appeal to ELISA membership is not a Linux safety certification claim, and using its tools is not evidence until they have a defined role in your safety plan.

What it does produce is dated and readable. The Linux Features for Safety-Critical Systems working group gave its annual update on 11 February 2026, presented by Alessandro Carminati of NVIDIA. Its 2025 work included a minimal Linux footprint — tracing real application behaviour to determine which kernel features are actually used — and memory isolation analysed through the lifecycle of Virtual Memory Areas. Both bear directly on the exclusion and freedom-from-interference arguments above, and both are investigative rather than a safety case. The workshop slides are published, and the next scheduled event is the Safe Systems with Linux microconference at Linux Plumbers in Prague, 5 to 7 October 2026.

What this means for the engineer holding the BSP

Three obligations follow from the classification and examination requirements, and a Linux safety certification will eventually ask you to produce all three.

The first is configuration identity: the configuration of the kernel that shipped, taken from the device rather than your build directory. Where the defconfig sets CONFIG_IKCONFIG_PROC, it is embedded in the kernel and readable at runtime:

root@s32g399aevb3:~# uname -r
root@s32g399aevb3:~# zcat /proc/config.gz > /root/running.config
root@s32g399aevb3:~# grep -E "^(# )?CONFIG_(PREEMPT|LOCALVERSION|MODULE)" /root/running.config

The pattern is anchored so it returns the whole CONFIG_MODULE family and not only the plural CONFIG_MODULES, and the # CONFIG_x is not set lines matter as much as the rest. This works on the NXP S32 automotive BSP because s32cc_defconfig sets CONFIG_IKCONFIG_PROC=y; not every vendor defconfig does. Given only a delivered image and no board, scripts/extract-ikconfig recovers the same data from the kernel binary.

The second is provenance and drift. Back on the build machine:

raghu@techveda.org:~$ git -C linux config --get remote.origin.url
raghu@techveda.org:~$ git -C linux describe --long --tags --always --dirty
raghu@techveda.org:~$ git -C linux log --oneline v6.12.92..HEAD
raghu@techveda.org:~$ scp root@s32g399aevb3:/root/running.config .
raghu@techveda.org:~$ linux/scripts/diffconfig running.config linux/.config

The first three establish which tree, which tag and which patches sit above the stable base. --tags is needed because a lightweight vendor tag is otherwise ignored, and --dirty because uncommitted patches are otherwise invisible. The last compares what shipped against what you think shipped. Empty output is the evidence, and only the output: diffconfig exits zero whether or not it finds a difference, and also when it cannot open a file. Treat it as an early drift check rather than proof of equivalence — it compares Kconfig symbols, so it says nothing about the compiler, the device tree, the modules or the image, and it ignores the version banner, which is why uname -r comes first on the board. For an out-of-tree or Yocto build the configuration is in the build directory, and the layer revisions matter as much as the kernel commit.

The third is the exclusion argument. Every subsystem, driver and feature built in but not required by the safety function is something you will be asked to justify, and under a classification that treats complexity as an explicit input, reducing the configuration is the most direct way to make the argument smaller. Setting CONFIG_LOCALVERSION_AUTO so that uname -r carries the git revision joins the first two obligations at no cost.

These three are the part of a Linux safety certification that belongs to the team holding the BSP, but they are not the whole evidence pack. What a safety programme actually asks for looks more like this, and the useful discipline is to produce it as a release artefact rather than reconstruct it under assessment.

On a Yocto-built platform this is worth emphasising: the kernel commit is not the whole provenance story. The layer revisions, the locked source revisions and the build configuration determine as much of what shipped as the kernel tree does, and a safety programme that records only the kernel commit will not be able to reproduce its own image. Assembling this is a different skill from writing kernel code, and it is the skill such programmes most often lack.

Key takeaways

• A Linux safety certification bounds a configuration on named hardware, assessed by a named body, with assumptions transferred to the integrator. It is not a property of the kernel, and it does not give your item its ASIL.
• ISO/PAS 8926:2024, published 29 January 2024, defines the route by which a pre-existing element enters an ISO 26262 argument, using classification rather than full qualification. Complexity is an explicit input, which makes configuration reduction the central activity.
• ISO 26262-8:2018 moved to “to be revised” on 8 July 2024 and a draft successor is under development; no publication date is public, so do not plan around it.
• Separate certified, certifiable and a safety package is available. Only the first names an assessor, though ISO 26262 requires an assessment rather than a certificate.
• A Linux safety certification is a controlled baseline, not a frozen one: every patch, rebase and toolchain change needs an impact analysis against the certified scope.
• ELISA states on its own site that it does not certify Linux.
• Configuration identity, provenance and an exclusion argument are what the team holding the BSP will be asked to produce.

Frequently asked questions

Is the Linux kernel certified to ISO 26262?
No. A Linux safety certification attaches to a defined product configuration on named hardware, assessed by a named body against a named edition and integrity level. Red Hat’s In-Vehicle Operating System, for example, is certified by exida against ISO 26262 Edition 2 (2018) as a Safety Element out of Context at ASIL-B.

Why does kernel configuration matter so much to a safety argument?
Because the examination of a pre-existing element requires showing that unused functionality cannot interfere or has been excluded, and ISO/PAS 8926:2024 names build-process configuration settings as the way that is done. Without an exact record of the shipped configuration the argument cannot be made.

Does a supplier certificate give my item its ASIL?
No. A Safety Element out of Context is assessed against an assumed integrity level, while the level your item needs comes from your own hazard analysis. The certificate establishes capability on condition that the Assumptions of Use hold in your design.

Does a matching kernel configuration prove the delivered image is the one you built?
No. It shows the Kconfig selections match. It says nothing about the patch stack, the compiler, the device tree, the modules or the final binaries, so pair it with the source commit identity and hashes of what was delivered.

Does ELISA membership mean a platform is safety certified?
No. ELISA’s own workshop write-up published on 27 August 2026 records that it does not certify Linux and does not guarantee the safety of a complete product. It produces shared analysis, processes and tooling instead.

Further reading

• ISO, ISO/PAS 8926:2024 — Use of pre-existing software architectural elements. A preview of the opening clauses is published free of charge; the clauses this article does not describe are in the paid text.
• ISO, ISO 26262-8:2018 — Part 8: Supporting processes. Carries the subject list and the current revision status.
• Red Hat, press release of 20 May 2025 on the In-Vehicle Operating System certification.
• ELISA Project, Working Groups, and the ELISA Workshop London 2026 highlights with published slides.
• ELISA Project, Linux Features for Safety-Critical Systems annual update, presented 11 February 2026.

This article is technical commentary on Linux safety certification, based on the sources named above and read on 4 September 2026. It is not certification advice and does not replace the purchased standard, a supplier safety manual, or a qualified assessor.