ITS Station Operators and Infrastructure Owners (IOOs) depend on Public Key Infrastructure (PKI) providers to manage the lifecycle of digital certificates that authorize device and application behaviour. Lifecycle management includes certificate issuance, validation, renewal, revocation, and trust list administration. The goal is to ensure that only eligible devices with verified cryptographic keys and compliant behaviour are allowed to operate within a C-ITS or V2X environment.
The PKI ecosystem includes multiple interrelated functions: certificate issuance, revocation, entitlement authorization, misbehaviour management, and trust list governance. As shown in the below diagram, these elements interact to support secure, policy-aligned credential management across jurisdictions.
While IOOs do not operate the PKI themselves, they must actively manage interactions with PKI providers and ensure their devices maintain trustworthiness throughout the credential lifecycle.
Applies To
IOOs, RSUs, OBUs, TMC Systems, PKI Providers, Trust List Managers
Used For
Certificate enrolment, revocation monitoring, trust list enforcement, misbehaviour integration
This pattern establishes a secure, standards-aligned process for onboarding ITS devices into a 1609.2-based PKI environment. It applies to both North American SCMS and European CCMS/C-ITS deployments, using defined enrolment and operational certificate flows to enforce trust, authorization, and revocation readiness.
Devices receive long-term enrolment credentials (ECs) and short-lived operational certificates (e.g., Authorization Tickets or pseudonym certificates). These are used to assert device identity, enable privacy-preserving communication, and support access control enforcement. All issued credentials must be traceable to trusted Root Certificate Authorities, as defined in the Certificate Trust List (CTL).
Pre-qualification and Testing: Devices must meet cryptographic, networking, and security control requirements established by the PKI’s CP/CPS or onboarding authority. (See OMNIAIR Test Case List, v1.0.)
Key Pair Generation: Keys must be generated on-device using secure hardware modules (e.g., TPMs, SEs, HSMs), and marked as non-exportable.
Initial enrolment: The device uses its EC to authenticate with the PKI and requests pseudonym or operational certificates containing appropriate PSIDs or ITS-AIDs with SSP constraints.
Authorization Ticket Handling: Devices may request batches or rolling sets of short-term certificates for message signing. Certificates include validity constraints and permissions to support least privilege and privacy.
Trust Anchor Provisioning: A CTL must be installed on the device, containing trusted root and intermediate CAs. Devices must reject any certificate chains not rooted in this CTL.
Lifecycle Support: Devices must support certificate renewal, re-enrolment (e.g., after reset or key loss), and revocation status validation using CRLs or online checks.
Privacy and Rotation: Devices rotate short-term certificates according to jittered schedules to limit traceability. Implementations must respect system-level policies on pseudonym rotation.
Defines certificate structure, revocation and signature requirements
IEEE 1609.2.1
Defines enrolment and authorization credentials, and secure provisioning workflows
SCMS Manager EE Security Requirements
Defines U.S. requirements for secure key handling, privacy protection, and revocation
EU C-ITS Certificate Policy
Operational and policy requirements for enrolment and issuance
ETSI TS 102 941
C-ITS trust and certificate handling in EU deployments
ETSI TS 103 097
Profiles for EU Authorization Tickets and pseudonym certificates
Pattern M3: ITS Cybersecurity Audit and Compliance Checks¶
Ensures that ITS components and systems maintain alignment with approved cybersecurity policies and configuration baselines over time. This pattern uses audit mechanisms and automated compliance verification to detect deviations in device behaviour, software, certificate usage, and trust relationships. It supports both proactive governance and reactive incident investigation by generating a record of configuration states and security-relevant events.
Used in operational environments where long-lived ITS deployments require ongoing verification of cybersecurity posture. Applicable to roadside units, backend infrastructure, and mobile devices.
Devices and backend systems must record security-relevant events (e.g., configuration changes, certificate usage, access attempts) in tamper-resistant logs.
Compliance Policies
Defined criteria that describe acceptable configurations, certificate parameters, software versions, and trust settings.
Verification Tools
Automated or manual processes that check actual system state against declared policies.
Time Synchronization
Audit logs must use synchronized, trustworthy timestamps to support forensic traceability.
Remediation Mechanisms
Actions taken when non-compliance is detected, such as revoking credentials, triggering alerts, or requiring reconfiguration.
Establishes a structured, repeatable process for detecting, triaging, responding to, and recovering from cybersecurity incidents that affect ITS systems. This pattern enables organizations to maintain operational continuity and protect system trust by formalizing how incidents are logged, escalated, and resolved. Incident management includes both organizational procedures (e.g., roles, escalation paths, post-incident analysis) and technical enablers (e.g., alert interfaces, remote disablement). It applies to infrastructure operators, certificate authorities, backend service providers, and other trusted participants in the ITS ecosystem.
Incident management applies to any ITS deployment where cybersecurity events may affect the integrity, availability, or trustworthiness of system components. It is particularly relevant for agencies managing field equipment, backend systems, or V2X services.
Documents procedures, escalation chains, contact information, and defined response timelines for anticipated ITS-specific incident types.
Monitoring and Alerting
Enables real-time visibility into system behaviour via local anomaly detection, misbehaviour reports, backend log aggregation, and threshold-based alerting.
Credential Revocation and Trust Change
Ensures that response actions include revoking affected certificates or restricting trust relationships, aligned with SCMS/CCMS procedures.
Forensic Evidence Collection
Devices and backend systems must log events, message traces, and anomalies in a tamper-resistant, time-synchronized manner for later investigation.
Stakeholder Communication
Protocols for notifying affected parties, such as OEMs, IOOs, or SCMS managers, and for fulfilling regional disclosure requirements.
Recovery and Lessons Learned
Post-incident reviews should identify root causes, update playbooks, and guide system or policy improvements.
Define an ITS-specific incident taxonomy, covering events such as credential theft, unauthorized message transmission, backend compromise, or device tampering.
Map each incident type to containment actions (e.g., device isolation, credential revocation), and clearly define the authority and authentication required to execute these actions.
Ensure that every field device and backend component supports audit logging, credential status reporting, and if feasible, remote disablement.
Require vendors to document and test their device response behaviour during simulated incidents.
Incorporate incident response training into operator SOPs, and conduct table-top or live exercises annually.
A traffic management center is compromised by ransomware. Systems are isolated from the network, incident response teams begin recovery procedures, and affected stakeholders are notified.
Unexpected Firmware Detected
A device reports a firmware version that does not match the approved baseline. The system flags it for containment and a field inspection is scheduled.
Operators must actively monitor for misbehaviour within their ITS networks and support reporting, adjudication, and remediation. misbehaviour refers to message-level or behavioural anomalies—either malicious or accidental—that degrade system trust or operational safety. A full misbehaviour lifecycle includes detection (local or backend), secure reporting, verification by an adjudicating authority, and proportional remediation (e.g., revocation, certificate issuance pause, or software update).
Configure devices for local detection. Use plausibility checks and rule-based filters to flag suspicious activity, such as falsified position or signal pre-emption attempts.
Enable structured logging. Capture message metadata, certificate info, and system state at time of anomaly for forensic analysis.
Transmit signed reports. Devices must support secure misbehaviour report generation using cryptographically bound evidence.
Set up a backend adjudication workflow. Define procedures to investigate reports, determine attribution, and assess severity and impact.
Support remediation actions. Integrate with certificate revocation or suspension mechanisms, such as CRLs, issuance pause, or software rollback.
Define policy and thresholds. Specify which types of misbehaviour trigger which level of response—revocation, temporary suspension, warning, etc.
Train operators. Staff must understand the full lifecycle: detection → reporting → adjudication → remediation → reinstatement.
Perform after-action reviews. Continuously improve detection policies and processes based on incident learnings.
Secure Remote Management ensures that ITS devices deployed in the field (e.g., RSUs, traffic signal controllers, or roadside sensors) can be administered without exposing them to unauthorized access, tampering, or disruption. Remote access introduces risks of credential theft, privilege escalation, or data interception; this pattern provides controls for secure communication, authentication, authorization, monitoring, and update processes.
This pattern applies to Infrastructure Owners and Operators (IOOs), device vendors, and system integrators who deploy and maintain ITS devices that require remote administration.
Applies To
IOOs, device vendors, integrators
Used For
Secure device administration, field maintenance, remote monitoring and updates
Dependencies
Public Key Infrastructure (PKI), secure communication protocols (TLS/DTLS, IPsec), centralized identity and access management
