EU C-ITS Mandate 2027: Engineering Implications for Nordic Transport Infrastructure

The EU C-ITS mandate 2027 Nordic transport infrastructure engineering workload is no longer a future planning exercise - it is an active delivery program that transport agencies and infrastructure operators in Denmark, Sweden and Finland must execute against within the next 18 to 24 months. The Delegated Regulation supplementing Directive 2010/40/EU (the ITS Directive) and the revised ITS Directive (EU) 2023/2661, together with the C-Roads Platform interoperability specifications, impose concrete engineering obligations on road authorities, tunnel operators, motorway concessionaires, and public transport infrastructure owners across all Nordic EU member states.

This article is written for Program Directors and VPs of Engineering at Nordic transport agencies and infrastructure operators. It assumes you already know the European Commission's direction of travel on Cooperative Intelligent Transport Systems and focuses on what you actually have to build: which systems are in scope, what the engineering work looks like, where the capacity gap sits in the Nordic labour market, and how to sequence delivery so that the 2027 milestones are achievable without destabilising live operations.

What This Article Covers at a Glance

• C-ITS is a mandated operational capability, not an innovation project: the revised ITS Directive (EU) 2023/2661 makes Day 1 and Day 1.5 services legally required for designated road segments and infrastructure categories.
• The scope covers roadside units, back-office C-ITS stations, and central ITS platforms: not just vehicle-side technology, which is a common misreading that leaves agencies under-scoped.
• Denmark, Sweden and Finland must each align with C-Roads Platform harmonised specifications: the national programs (ITS Denmark, Trafikverket, Fintraffic) have public roadmaps you can align against.
• The engineering capacity gap is concentrated in embedded systems, IEC 62443 security, and V2X protocol stacks: these are specialist skills the Nordic market currently prices at a premium.
• Compliance is tested against specific standards: ETSI EN 302 637-2/3 (CAM/DENM), ETSI TS 103 097 (security), ISO 21217 (station architecture), and the C-Roads technical profiles.
• Sequenced delivery is possible: by decoupling roadside hardware procurement, back-office platform engineering, and integration testing into parallel workstreams with clear interface contracts.

What Does the EU C-ITS Mandate Actually Require of Nordic Transport Agencies?

The EU C-ITS mandate is best understood as a set of three overlapping obligations, not a single regulation. Nordic agencies need to map their infrastructure portfolio against all three to understand their scope accurately.

First, the revised ITS Directive (EU) 2023/2661, which entered into force in December 2023, extends the scope of EU-level ITS specifications from the Trans-European Transport Network (TEN-T) to the comprehensive network and to urban nodes. This is the operative change. Infrastructure that was previously outside the mandate now falls inside it. Tunnel operators, urban traffic management centres, and public transport infrastructure owners in all three Nordic EU member states are affected.

Second, the Delegated Regulation 2023/1704 on Multimodal Travel Information Services and related delegated acts on real-time traffic information and safety-related traffic information require data provision in specified formats via the National Access Points. For Denmark, Sweden and Finland, this means the national NAP operators (Vejdirektoratet, Trafikverket, Fintraffic) must ingest, validate and publish data from infrastructure owners in DATEX II and related formats, which creates engineering obligations on the data-producing operators.

Third, the C-Roads Platform harmonised specifications define the technical profiles for C-ITS Day 1 services (hazardous location notifications, road works warning, in-vehicle signage, probe vehicle data, signal phase and timing, signal violation warning, green light optimal speed advisory, and stationary vehicle warning). These are the services that must be operational on designated road segments. The C-Roads Platform Release 2.1 specifications, aligned with ETSI ITS G5 and the Hybrid Communication approach, define exactly what messages must be emitted, at what frequency, with what security signing, and through what communication channels.

When agencies talk about the "2027 mandate," they usually mean the convergence of these three tracks against national implementation timelines aligned with the EU Sustainable and Smart Mobility Strategy milestones.

Which Systems Are in Scope for Nordic Infrastructure Operators?

The scope question is where most early programs go wrong. The common mistake is treating C-ITS as a roadside unit (RSU) procurement exercise. It is not. It is a system-of-systems engineering program with four distinct layers.

Layer one is the roadside C-ITS station. This is the embedded hardware and software deployed at gantries, traffic signal controllers, variable message signs, tunnel portals, and work zones. It runs an ITS-S architecture compliant with ISO 21217, emits CAM and DENM messages per ETSI EN 302 637-2 and ETSI EN 302 637-3, and handles security per ETSI TS 103 097 with certificate management via the European C-ITS Security Credential Management System (EU CCMS).

Layer two is the central C-ITS station, sometimes called the back-office. This is where traffic management centre data is transformed into standardised C-ITS messages and routed to the relevant roadside infrastructure or broadcast via cellular. The central station is typically the integration point between legacy traffic management platforms (SCOOT, SCATS, proprietary Nordic TMC platforms) and the C-ITS message layer.

Layer three is the security and certificate infrastructure. Nordic operators must integrate with the EU CCMS (via enrolment authorities and authorisation authorities) and manage certificate lifecycles for every C-ITS station in their estate. This is specialised PKI engineering work and is frequently underestimated in initial scoping.

Layer four is the data exchange and monitoring plane. Integration with National Access Points, inter-operator message exchange via the C-Roads reference architecture, operational monitoring, key performance indicator collection, and the evidence base for regulatory reporting all live here.

An honest scope statement for a typical Nordic motorway operator covers all four layers, not just layer one.

What Engineering Work Is Required for C-ITS Compliance?

Once the scope is correctly framed, the engineering work decomposes into a reasonably predictable set of workstreams. Any Nordic agency planning a 2027-aligned delivery should have budget and team structure against each of these.

Protocol stack implementation covers the ETSI ITS-G5 physical and MAC layers, GeoNetworking, BTP, and the facilities layer where CAM, DENM, IVI, SPaT, MAP and SSM messages are generated and consumed. On the cellular side, the equivalent work includes the 3GPP C-V2X Release 14 or later stack and the hybrid-mode logic that chooses between short-range and cellular paths.

Message engineering covers CAM generation logic (which is non-trivial for stationary infrastructure because the standard is vehicle-centric and must be adapted), DENM triggering logic tied to operational events, IVI content mapping from existing traffic sign datasets, and SPaT/MAP generation from signal controller state.

Security engineering covers integration with the EU CCMS, enrolment and authorisation certificate workflows, pseudonym management, signing and verification of outbound and inbound messages, and revocation handling. This work must be delivered to IEC 62443 standards because C-ITS stations are industrial control components in the revised NIS2 regulatory framing.

Integration engineering covers the interface between existing traffic management platforms and the central C-ITS station, the interface with the National Access Point, and the inter-operator message exchange. This is usually the longest-pole workstream because it requires coordinated testing with parties outside the agency's direct control.

Test and validation engineering covers conformance testing against ETSI test specifications, interoperability testing aligned with C-Roads test events, security testing for the PKI integration, and acceptance testing against operational scenarios. The C-Roads Platform publishes test specifications that serve as a reasonable baseline.

Where Is the Engineering Capacity Gap in the Nordic Market?

The Nordic labour market is tight for C-ITS-relevant skills, and agencies planning 2027-aligned delivery need a realistic view of where they can and cannot staff internally.

At the protocol and embedded systems layer, the available talent pool in Denmark, Sweden and Finland is narrow. ETSI ITS-G5 and C-V2X experience is concentrated in a small number of Tier 1 suppliers and a handful of specialist consultancies. Graduate pipelines exist (Aalto University, KTH, DTU have relevant programs) but do not produce senior engineers in the volume needed for the current wave of mandated programs.

At the security and PKI layer, IEC 62443 expertise is easier to find than C-ITS-specific PKI experience. The latter is a small specialism globally and commands a significant premium in the Nordic market.

At the integration layer, DATEX II and traffic management platform expertise exists in the Nordic system integrator community, but integration with the European C-ITS Security Credential Management System is less common.

Most Nordic agencies respond to this capacity reality by combining an internal architectural and program management core with a sub-partner engineering model. A Nordic prime (often a domestic SI or Tier 1 supplier) retains accountability to the agency, while a strategic engineering partner provides the embedded systems, protocol stack, and test automation capacity at the scale and pace required. This is the model we describe in our analysis of sub-partner engineering teams for Nordic system integrators, and it is directly relevant here.

What Does a Realistic C-ITS Delivery Timeline Look Like?

A 2027-aligned delivery program running today has roughly 18 to 24 months of engineering runway. The following sequence is a conservative but achievable pattern, assuming scope is confirmed and funding is in place.

Months 1 to 3 cover architecture and interface definition. The central C-ITS station architecture is baselined, the interface contracts with the existing traffic management platform and the National Access Point are specified, the PKI integration design is agreed with the national enrolment authority, and the roadside unit hardware procurement specification is finalised.

Months 3 to 9 cover parallel delivery of the central C-ITS platform, the protocol stack for roadside deployment (if not procured off the shelf), and the PKI integration. In this window it is also usual to run a small-scale field pilot on a limited set of gantries and signal controllers to validate the end-to-end chain before wider rollout.

Months 9 to 15 cover rollout of roadside hardware, integration testing at scale, and participation in C-Roads interoperability test events. This phase is where schedule risk most often materialises because it depends on coordinated testing with parties outside direct control.

Months 15 to 21 cover operational readiness, evidence collection for regulatory reporting, and handover to operations. The evidence base (test reports, conformance certificates, PKI operational logs, KPI dashboards) is non-trivial and should be built as part of delivery, not assembled retrospectively.

Months 21 to 24 provide a contingency buffer and cover defect resolution from initial operations.

Programs starting meaningfully later than this will struggle to hit 2027 without either reducing scope or accepting derogations, both of which are political decisions above the program director level.

Which Compliance Standards and Frameworks Must Nordic Operators Map Against?

The compliance surface is broad but finite. The following set is a reasonable baseline for any Nordic C-ITS program and should form the core of the regulatory traceability matrix.

On the ITS Directive side, the revised Directive (EU) 2023/2661 and its associated delegated acts on real-time traffic information (Regulation 2015/962), safety-related traffic information (Regulation 886/2013 as amended), and multimodal travel information (Regulation 2017/1926 as amended) define the outputs expected of infrastructure operators.

On the C-ITS technical side, the ETSI TC ITS standards define the message formats and protocol stack. The relevant baseline includes ETSI EN 302 637-2 (CAM), ETSI EN 302 637-3 (DENM), ETSI TS 103 301 (infrastructure messages including IVI, SPaT, MAP, SRM, SSM), ETSI TS 103 097 (security), and ETSI EN 302 665 (communications architecture). ISO 21217 covers station architecture.

On the security side, the EU CCMS Certificate Policy and the C-Roads security specifications define the PKI requirements. Industrial cybersecurity obligations flow from IEC 62443-4-1 (secure product development lifecycle) and IEC 62443-4-2 (component requirements) for the embedded C-ITS stations, and IEC 62443-3-3 for the system-level requirements.

On the operational side, NIS2 transposition in each Nordic country creates incident reporting and supply chain security obligations. GDPR applies to any personal data processed (including vehicle identifiers that may become personal under certain conditions) and should be assessed formally.

Readers evaluating the broader German ITS engineering standards context, and how they transfer to Nordic infrastructure, will find the analysis in our piece on ITS engineering for Nordic transport directly relevant.

Executive-Level FAQ on the C-ITS Mandate

How does the EU C-ITS mandate apply to Sweden, Denmark and Finland specifically?

All three are EU member states and are therefore bound by the revised ITS Directive (EU) 2023/2661 and its delegated acts on the same basis as any other member state. National implementation is run by Trafikverket in Sweden, Vejdirektoratet in Denmark, and Fintraffic and the Ministry of Transport and Communications in Finland, with C-Roads participation through the national programs. Each has a publicly stated roadmap aligned with the EU 2027 milestones.

Do we need to deploy ITS-G5, C-V2X, or both?

The EU framework is technology-neutral and the C-Roads Platform has adopted a Hybrid Communication approach. Most Nordic programs are planning for a hybrid deployment that supports both ETSI ITS-G5 short-range communication and cellular C-V2X, with the central C-ITS station abstracting the communication choice per message and per road segment. Single-technology deployments are possible but reduce future flexibility.

Can we rely on Tier 1 suppliers to deliver turnkey compliance?

Partially. Tier 1 roadside unit suppliers deliver compliant hardware and protocol stacks, but the central C-ITS station, the integration with the national traffic management platform, the PKI integration with the EU CCMS, and the NAP integration are typically out of scope for hardware suppliers and must be engineered separately. Programs that assume turnkey Tier 1 delivery without an integration engineering capability consistently under-scope.

What is the biggest single risk to hitting the 2027 milestone?

In our experience working with European transport operators, the biggest single risk is the integration testing phase, specifically coordinated testing with external parties (NAP operators, other infrastructure owners, vehicle OEMs at C-Roads test events). This phase depends on calendar coordination outside the program's direct control and compresses remaining schedule quickly. Programs that finish their internal engineering late almost always miss external test windows.

What Should Nordic Infrastructure Leaders Do Next?

If your program is already mobilised, the immediate priority is confirming scope across all four architectural layers and honestly assessing the capacity gap in embedded systems, C-ITS PKI, and V2X protocol engineering. If your program is not yet mobilised, the compression of the remaining delivery window is now material and architectural decisions taken in the next quarter will determine whether a 2027 milestone is achievable without derogations.

For Nordic agencies and infrastructure operators weighing how to structure the delivery team - internal, prime contractor, or a blended model with a strategic engineering partner supplying embedded systems and test automation capacity - the question is best framed as a capacity and risk question, not a cost question. The engineering content is specialist and the timeline is unforgiving. The decision that matters most is securing the right engineering capacity, with the right standards track record, on contract and integrated before the external test windows start to close.