Safeguard
Compliance•

What is an RXSWIN and why UN R156 needs one

An RXSWIN is a regulatory software identifier defined by the manufacturer under UN R156. Learn what it encodes, who reads it and how to manage it.

Safeguard Security Team
3 min read

An RXSWIN is a software identification number that a vehicle manufacturer defines under UN R156 for software that is relevant to type approval. It can be read from the vehicle, so authorities can check the homologation status of that software. Each software version in each vehicle type should get a unique one.

What the name encodes

The first part indicates the UN regulation number. UL gives the example of RX79 for Regulation No. 79, which covers steering. The rest is a manufacturer defined version identifier. Sources differ on how the acronym is expanded, with one calling it the Regulatory Software Identification Number and another calling it the Regulation X Software Identification Number, so use the term as written in the regulation text you work with.

Why it exists

Type approval is granted for a vehicle as built. If software that affects an approved function changes, the approval may be affected. Without a stable identifier, an authority has no easy way to tell which software a given car actually carries.

The RXSWIN gives that answer. A manufacturer must be able to show which software versions sit behind each RXSWIN and assess whether each update affects existing approval.

What the manufacturer has to keep

According to UL's summary of R156, a SUMS needs records such as:

  • Hardware and software versions for each system and function.
  • The vehicle configuration documentation.
  • Which software needs an RXSWIN, with interdependencies and affected components.
  • Documentation of all SUMS processes.

Think of it as a bill of materials for software that matters to approval. It is similar in spirit to an SBOM, but its purpose is regulatory identification rather than vulnerability tracking.

A practical way to manage it

  1. List every control unit and function with type approval relevance.
  2. Decide which software items need an RXSWIN and write down the rule.
  3. Tie each RXSWIN to a build, a hardware version and a release record.
  4. Make the identifier readable on the vehicle, and test that the value matches the record after each update.
  5. When an update changes behavior, record whether the RXSWIN changes and why.

Common mistakes

Teams often treat the identifier as a label added at the end. It works better as a release gate: no release candidate leaves engineering without a recorded identifier and an impact assessment. Another mistake is forgetting workshop updates. R156 applies to wired updates as well as over the air ones.

Evidence an auditor may ask for

Expect to show the rule that decides which software gets an identifier, a sample of records linking identifiers to builds, and proof that a vehicle reports the right value after an update. Keep the change history too. If an update did not change the identifier, be ready to explain how you judged that it left the approval untouched.

Quick check

Is the RXSWIN the same as a software version number?

No. It is a regulatory identifier tied to a regulation number. It relates to your internal versions through your records.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.