Insights / Embedded & Firmware
Microchip Connectivity Framework (MCF): End-to-End Security for IoT Messaging
How MCF adds an encrypted layer above any embedded link, keeps keys with the customer, and compares with other IoT messaging-security frameworks.
The short answer
The Microchip Connectivity Framework (MCF) is a set of software libraries and tools that adds an encrypted application layer between embedded devices, gateways, PCs and mobile apps. It runs above whatever link carries the bytes (UART, CAN, Ethernet, Wi-Fi, Bluetooth and others) and routes traffic through an on-premises or cloud server, typically a standard MQTT broker, that cannot read message content. Each node is identified by a certificate chain that the customer, not the cloud vendor, owns.
Why link-level security leaves a gap in IoT messaging
Connected devices rarely stand alone. A sensor talks to a gateway over CAN or Bluetooth, the gateway talks to a broker in the cloud, and a phone or PC reads the result. One weak device can expose everything it is connected to, and well-known incidents have shown attackers moving from a single compromised gadget into a much larger network.
The usual defences are encryption, strong authentication of every device, and lightweight messaging protocols such as MQTT that keep code size and power within what a microcontroller can afford. The problem is where encryption ends. TLS protects one hop, so traffic is decrypted at the broker or cloud service, and links such as UART, SPI or CAN often carry no security at all. Whoever runs the server can see the data, and each link needs its own protection.
- End-to-end encryption (IoT)
- Encryption applied by the sending node and removed only by the intended receiving node, so gateways, brokers and cloud services in between forward messages they cannot read.
How MCF works: one secure layer above any link
MCF operates at the application layer. It needs only access to an input and an output buffer managed by the existing drivers and stacks, so it can sit on top of almost any underlying channel. Two nodes then share a secure channel at the MCF layer, whatever links lie between them.
| Property | What it means in practice |
|---|---|
| Protocol abstraction | One common protocol for every node, whether the link is UART, SPI, I2C, USB, CAN, 10BASE-T1S, Ethernet, Wi-Fi, IEEE 802.15.4 or Bluetooth |
| Private by design | The local server vendor or cloud provider routes messages but cannot read their content |
| Cloud-agnostic | The cloud extension is a standard MQTT broker plus a small application, so an instance can move between providers or run on premises |
| Topologies | Point-to-point, star and mesh, with built-in session forming, routing and redundancy |
| Footprint | Around 20–30 kB of flash on the device; suitable for 8-, 16- and 32-bit MCUs and for MPUs |
| Cryptography | ECDSA signatures (FIPS 186-3), ECDH key agreement (NIST SP 800-56A) and HKDF key derivation (NIST SP 800-56C) |
| Hardware keys | Optional USB hardware keys hold the end-to-end keys on PCs and similar hosts |
Clusters, gateways and node identity
An MCF network is built from clusters. Each cluster has one gateway and one or more nodes; every node either joins a gateway or becomes one. The gateway keeps and shares the list of participating nodes, and communication between nodes is secured end to end.
To open a secure session, each node proves its identity with a certificate chain: CA, server, intermediate and device thumbprints, about 600 bytes of credentials in total. The device thumbprint itself is 150 bytes: a 9-byte subject serial number, a 9-byte issuer serial number, a 64-byte public key, a 4-byte expiry date and a 64-byte signature.
- Device certificate: identifies the node by serial number and public key, signed by an intermediate certificate authority.
- Server certificate: identifies the server the same way, also signed by an intermediate authority.
- Intermediate CA: signed directly by the root CA.
- Root CA: owned and managed by the customer, not by the cloud vendor.
On embedded devices the intermediate and device certificates can live in flash or in a secure element; the server and CA certificates live in flash. With a secure element, the private key is generated inside the chip and never leaves it. In the most secure flow, Microchip creates an intermediate key pair that the customer's CA signs, and each secure element's public key is turned into a device thumbprint signed by that intermediate.
How MCF compares with other IoT messaging-security frameworks
Research has produced several security frameworks for specific kinds of IoT network. Each solves a real problem, but most are tied to one domain or stop at assessment rather than implementation.
| Framework | Focus | Approach | Main limitation |
|---|---|---|---|
| ECG-based key generation for medical data | Healthcare wearables | Derives unique keys from a patient's ECG signal (QRS complex) and uses them for authentication | Only works where ECG data is already collected |
| Lightweight framework for inventory automation | Inventory and logistics networks | Device registration with an inventory server, hash-based mutual authentication and lightweight XOR-and-permutation encryption | Untested outside inventory systems |
| Secure and Compliant Continuous Assessment Framework (SCCAF) | Choosing and monitoring cloud providers | The customer defines security metrics, assesses providers against them and re-checks compliance in use | Prescribes no encryption or controls; the customer must build the metric set |
| Enhanced security framework for smart homes | Smart home appliances | Manufacturer-signature integrity checks, role-based mandatory access control and continuous authentication | Not lightweight; an attack that slows a device without breaking its role goes unnoticed |
| MCF | Any embedded network | Application-layer end-to-end encryption with customer-owned certificates over any underlying link | Adds a provisioning and certificate lifecycle the product team must own |
The common lesson is layering. Present-day designs combine device identity, authentication and encryption, and keep the protocol light enough for a microcontroller. MCF is one way to put that layer in place across mixed links; the alternative is securing each hop separately and accepting that intermediaries see the data.
What this changes for a product team
Adopting an application-layer framework moves security decisions earlier. Firmware has to integrate the stack with each driver's buffers, budget the flash, and decide where keys are stored. Manufacturing needs a provisioning step. The cloud side becomes simpler to trust, because the broker no longer needs to be trusted with content.
End-to-end encryption also maps onto parts of security standards and regulations, such as the secure communication and sensitive-data provisions of ETSI EN 303 645 and the data-protection requirements in ISA/IEC 62443. It does not by itself make a product or an organisation compliant: those frameworks also cover vulnerability handling, updates, development process and policy.
When MCF is worth evaluating
Consider an application-layer framework such as MCF if
- Data must stay private from the broker, cloud provider or integrator that carries it.
- Messages cross several link types (for example CAN or UART inside the device and Wi-Fi or Ethernet outside) and need one security model.
- The fleet runs on constrained MCUs where a full TLS stack per link is too heavy.
- You want to move between cloud providers or run on premises without re-keying devices.
- You can own a CA, a provisioning step in manufacturing and a certificate lifecycle.
- Hosts such as PCs or service tools need hardware-backed keys to join the network.
Questions engineers ask
What is MCF?
In IoT security, MCF is the Microchip Connectivity Framework: software libraries and tools that add an end-to-end encrypted application layer between embedded nodes, gateways, PCs and mobile apps, over any underlying link and through a server that cannot read message content.
Can the cloud provider read MCF messages?
No. The cloud extension routes messages through a standard MQTT broker, but content is encrypted end to end between nodes, and the certificate authority is owned by the customer rather than the cloud vendor.
Was this useful?
Where this shows up in our work
ExpertiseEmbedded and firmware engineeringIntegrating an application-layer security stack means firmware work on drivers, buffers and key storage, plus a provisioning flow for the factory and field. Our embedded team designs that with the cloud side.Where device data is patient data, end-to-end encryption and customer-owned keys carry extra weight. See Healthcare.
Apply this to your product