ITS RoadsCV2X

Guides › SCMS for roadside units: certificates, bootstrapping, providers and what an agency has to do

Updated 2026-10-08

Why your RSU needs certificates

Every message a roadside unit broadcasts is wrapped in an IEEE 1609.2 secured PDU and signed. Vehicles discard unsigned messages and messages signed by a certificate they cannot trace to a trusted root. The Security Credential Management System (SCMS) is the public-key infrastructure that issues those certificates, publishes revocation lists, and handles misbehavior reports. Without it an RSU can transmit, but nothing listens.

The pieces

  • SCMS Manager LLC (scmsmanager.org) is the US industry body that sets the policies and interoperability profiles, audits providers, and operates the Elector model: five electors sign the Certificate Trust List (CTL) that every device uses to decide which root certificate authorities to trust. Key documents: the IEEE 1609.2.1 SCMS Manager Profile v1.0.3, the End-Entity Security Requirements v2.04, the Provider Requirements v1.1 and the elector certificates and CTL.
  • Providers operate the certificate authorities. The provider with public agency onboarding today is OmniTrust, formerly Integrity Security Services (ISS), with its TrafficAuth-SCMS service listed on the CTL (trafficauth.com, root CA policy). ITE's connected-intersection reference list also names AutoCrypt, BlackBerry, ESCRYPT, SAESOL Tech and Microsec as PKI vendors; several of them have demonstrated cross-provider interoperability at OmniAir plugfests.
  • Standards: IEEE 1609.2 (the SPDU and certificate formats; 1609.2-2025 published October 2026) and IEEE 1609.2.1 (the certificate management protocols between a device and the SCMS; 1609.2.1-2026 supersedes the 2022 edition). CTI 4001 requires an RSU to enroll with an owner-approved SCMS over the 1609.2.1 interfaces and to hold application certificates for at least WSA, SPaT, MAP, TIM, RSM and SSM.

Certificate types an RSU holds

  1. Enrollment certificate. Issued once by the Enrollment CA during a secure bootstrap, which SCMS Manager requires to happen in a controlled environment with an approved process. It identifies the device to the Registration Authority and is used only to request other certificates. Re-enrollment issues a successor certificate that becomes valid when the current one expires.
  2. Application (authorization) certificates. What the RSU signs messages with. Each carries the PSIDs the RSU is allowed to use, with Service Specific Permissions, and is short-lived: the common profile is one week (168 hours) with a one-hour overlap, so the RSU must reach its SCMS at least weekly to top up. On an NTCIP 1218 unit this is rsuSecCredReq, the enrollment and application certificate URLs, and the CRL URL.
  3. Trust material. The root certificates, the CTL, the Certificate Chain File and the composite CRL, refreshed from the provider's distribution center.

Vehicles use pseudonym certificates with butterfly keys and linkage values for privacy; RSUs use ordinary identified application certificates, so a revoked RSU is listed by certificate hash on the CRL.

What an agency has to do

  1. Decide the applications before procurement. The PSIDs and SSPs on the certificates must match what the RSU will broadcast (SPaT, MAP, TIM, RSM, SSM, SDSM). USDOT's RSU lessons-learned report warns that devices enrolled with the wrong permissions may have to come down off the mast arm to be re-initialized.
  2. Pick who bootstraps. The vendor can bootstrap at the factory, the agency can do it on receipt, or a contractor can do it in a lab. Factory test certificates are often expired by the time units are installed, so plan for a production enrollment after delivery.
  3. Contract with a CTL-listed provider and register the deployment. OmniTrust/TrafficAuth maintains per-agency onboarding pages for existing DOT programs (for example FDOT, GDOT, CDOT, Caltrans); a new program requests a quote and accepts the subscriber terms. Test-service certificates are free; production is by quotation, typically a per-device, per-year subscription plus a program license.
  4. Give every RSU backhaul to the SCMS, at least weekly, through whatever firewall and VPN the agency uses, and monitor it.
  5. Procure devices that meet SCMS Manager end-entity requirements: hardware key storage (an HSM, often FIPS 140-2 Level 3), secure boot, and an OmniAir certification that includes the 1609.2 and 1609.2.1 certificate-acquisition tests.
  6. Plan for misbehavior reporting and revocation. SAE J3287 misbehavior detection is now a mandatory OmniAir test; providers must publish CRLs that reflect misbehavior reports, and USDOT advises agencies to require IEEE 1609.2.1 so a provider can be added or replaced without re-enrolling every device.

Check certificate health over SNMP

NTCIP 1218 exposes the security subsystem under 1.3.6.1.4.1.1206.4.2.18.8. Useful objects on live units:

ObjectMeaning
.8.2.0 rsuSecEnrollCertStatusEnrollment state (enrolled = 4; some vendors report other = 1 even when enrolled)
.8.6.0 rsuSecEnrollCertExpirationDays until the enrollment certificate expires
.8.8.0 rsuSecAppCertSourceURL the RSU uses for application certificates
.8.9.0 maxRsuSecAppCertsCapacity of the application certificate table
.8.10 rsuSecAppCertTableCurrent and future application certificates with their PSIDs and validity

We monitor these on state DOT fleets of Commsignia and Yunex units. A healthy unit shows a current and a future application certificate; a unit that cannot reach its provider shows the table draining toward expiry a week ahead. Vendors differ on how fully they implement the enrollment objects, so compare against a known-good unit of the same model before raising an alarm. Note that 1.3.6.1.4.1.1206.4.2.18.16.5.0 is rsuClockSource, not a security status, a mislabel that has caught at least one monitoring template.

References