This new technical notice outlines critical update considerations related to Microsoft .NET and the EU Cyber Resilience Act (CRA) that affect FDT 1.2.x products, including HOSTs (FRAMEs) and Device DTM solutions.
Key Points:
- FDT 1.2.x products that rely on the .NET-based product lifecycle will reach end-of-life by January 2029, due to their dependency on Microsoft .NET Framework 3.5.
- FDT 1.2.x is in maintenance-only status due to the obsolescence of Microsoft .NET Framework 3.5 (CLR2) and upcoming CRA regulations (starting September 2026). No new features or specifications will be developed for this version, including CRA support. Please review the original notice for details.
- FDT 2.x products are based on CLR4 and are not affected by the obsolescence of .NET Framework 3.5 (CLR2); however, they are affected by CRA regulations. FDT 2.x is also in maintenance-only status.
- Vendors are responsible for determining their own approach to migrating to newer .NET versions, to ensure their solutions meet CRA requirements, while maintaining interoperability for their end customers.
- It is recommended to develop a migration plan to support FDI as part of modernization efforts.
FDT 1.2.x Migration Considerations:
- Vendors of both HOST (FRAME) and DTM solutions can extend the lifecycle of FDT 1.2.x products through their own development efforts.
- Migration to .NET Framework 4.8.x (CLR4) is recommended, in alignment with Microsoft’s modernization guidance.
- Comprehensive regression and interoperability testing must be performed to ensure reliable operation. Please note that FieldComm Group will not require certification or compliance validation. FieldComm Group will facilitate multivendor interoperability efforts as needed by our membership to ensure interoperability for end customers.
Practical Path Forward for Continued Use:
Even without official specification updates, meeting CRA conformance and continuing operation is achievable by:
- Updating specific Microsoft runtime components within the HOST (FRAME).
- Performing full regression and interoperability testing.
Hard Technical Deadline:
- January 9, 2029 – Microsoft .NET Framework 3.5 officially reaches end-of-life (EOL); any software still loading CLR2 will no longer receive required security updates in the CLR.
- All FDT 1.2.x HOSTs (FRAMEs) running on CLR 2 must be migrated to CLR4 before this date.
Impact Scope:
| Component | Currently Runs On | Must Be Addressed? | Notes |
|---|---|---|---|
| HOST (FRAME) | CLR 2 (.NET 3.5) | YES (mandatory) | Upgrade required regardless of DTM status. |
| DTMs | CLR 2 or CLR 4 | Optional (business decision) | If the DTM is based on CLR2 but works in CLR4, no update is needed. |
Recommended HOST (FRAME) Vendor Interoperability and Migration Strategies:
(The Yes/No values in the table below indicate the interoperability between different FRAMES and DTMs)
| FRAME | DTM (CLR2) | DTM (CLR4) | DTM (COM) | COMMENTS |
| FRAME (CLR2) | Yes | No | Yes | CLR4-only assemblies cannot be loaded into a pure CLR2 managed application. |
| FRAME (CLR4) | Requires individual testing | Yes | Yes | The FRAME should migrate to CLR4 first, then DTMs should be checked for interoperability. Each DTM must be testing with each FRAME. |
| FRAME (CLR2+CLR4) | Yes | Yes | Yes | Recommended only for Dual-Runtime support (see below). DTM vendors decide whether to perform interoperability testing or recompile to CLR4. |
FDT 1.2.x Critical Update Considerations:
CLR4 Migration - Preferred Option
- Recompile the FRAME for .NET 4.x.
- Test DTMs for execution in CLR4.
- Some DTMs implemented with CLR2 may be executable in CLR4 without modification.
- Update DTMs, where required, to be executable in CLR4 (while DTM is still implemented with CLR2).
- Upgrade DTMs to CLR4 if necessary.
Dual-Runtime Support - Migration Option
(recommended for maximum backward compatibility)
- Upgrade FRAME to .NET 4.8.x (CLR4).
- Maintain the ability to load and run legacy CLR2 DTMs within the CLR2 host process (possible with .NET 4+ side-by-side CLR hosting).
- Thoroughly test all existing CLR2 DTMs after the upgrade to ensure interoperability.
Drop FDT 1.2.x support - Alternative Option
- Drop FDT 1.2.x support entirely and migrate to FDI or FDT 3.0 solution.
Critical Technical Constraint
A pure CLR2 process cannot load CLR4 assemblies in-process. Any DTM compiled exclusively for CLR4 will fail to load unless the HOST itself runs on CLR4 or the DTM is hosted out-of-process with IPC (inter-process communication).
Recommended DTM (Device Vendor) Options:
| Option | Description | Pros | Cons | Typical Use Case |
|---|---|---|---|---|
| Test & run as-is on CLR4 | Keep existing CLR2 binaries and validate that they work when loaded by a CLR4 HOST | Zero code changes, fastest option | Risk of subtle runtime incompatibilities | Low-maintenance devices, small install base |
| Recompile & retarget CLR4 | Rebuild the DTM against .NET 4.x and optionally re-register with FCG | Cleaner long-term option | Requires development and testing effort; new binary release | Actively supported devices, larger customer base |
Recommended Path Towards Modernization:
Align your migration plans before the end of 2027. FieldComm Group is developing an updated FDI specification to ensure .NET modernization, CRA compliance, IT/OT integration, nested communications, support for process and factory protocols, and comprehensive lifecycle management. 
Next Steps:
- Assess your current FDT FRAME/DTM stack and migration timeline.
- Connect directly with your service provider if you are seeking to mitigate your FDT solution.
- Prepare your solutions and development roadmap to support the updated FDI specification and development timeline. Please review the recent article for more information.
- Members can join the FieldComm Group working group community for FDT, FDI and Security/CRA harmonization teams, to stay connected with the latest activities.
- Contact FieldComm Group through the Support Portal via a 'ticket' with any questions.