Greengrass V1 Is Gone and IoT Edge 1.5 Ends 10 November: An Edge Runtime Drill

Two edge runtimes that a lot of connected products were built on have reached the end of their lives within five weeks of each other.

On 7 October 2026, AWS ended support for AWS IoT Greengrass Version 1. AWS's migration guide now says plainly that "the AWS IoT Greengrass V1 API operations and resources are no longer available." On 10 November 2026, Azure IoT Edge 1.5 LTS reaches end of servicing, on the same day as .NET 8, the runtime it is built on.

Neither deadline was a surprise. Greengrass V1 has been in its "extended life" phase since June 2023, and IoT Edge LTS releases have tracked the .NET LTS calendar for years. Even so, edge runtimes are the part of a connected product that most often gets installed once and then forgotten. They run on a box in a cabinet, on a gateway at a customer site, or on a Linux VM inside a Windows panel PC that nobody has logged into since commissioning.

This post covers what each change actually means, where I'd expect it to hurt, and what I'd do in the next few weeks.

What changed on 7 October: Greengrass V1

AWS's V1 maintenance policy defines three lifecycle phases. In the last one, "extended life", there are no more patches, but "the AWS Cloud endpoints and API operations will remain available." The same page describes what happens once that phase ends: "the AWS Cloud endpoints and API operations will be deprecated and no longer available. Devices that run the AWS IoT Greengrass Core software v1.x won't be able to connect to AWS Cloud services to operate."

That is where we are now. The V1 documentation carries a banner saying that after 7 October 2026, "you will no longer be able to access the AWS IoT Greengrass V1 resources."

AWS's pages describe the cloud side. They don't say what a V1 core already running in the field does locally once it can no longer reach the service. Don't guess, and don't assume it fails safely. If you still have V1 cores in production, take one that is representative and watch it: is local processing still running, are local subscriptions still delivering messages, and where is the data that used to go up to the cloud ending up now?

One detail is worth knowing because it shows how these deadlines get missed. When I opened the V1 maintenance policy page this week, the end-of-support banner was at the top. Further down, the "Deprecation schedule" section still said "there is no plan to stop supporting the AWS IoT Greengrass Core software v1.x" and that AWS would give "12 months advance notice." A team that searched the page for the deprecation section and read only that part could easily have come away reassured. The lesson isn't about AWS in particular. Vendor lifecycle pages are edited piecemeal, so track the dated notices, not the general policy text.

What changes on 10 November: Azure IoT Edge 1.5 LTS

Microsoft's lifecycle page lists Azure IoT Edge 1.5 (LTS) with an end date of 11/11/2026 06:59:59 Pacific, which is the end of 10 November. The IoT Edge release notes explain the reason: "IoT Edge 1.5 LTS aligns with .NET 8 and is supported until .NET 8 reaches end of support on November 10, 2026." Under Microsoft's lifecycle policy, end of servicing means no new security updates, no non-security updates and no assisted support.

The successor already exists. IoT Edge 1.6 LTS shipped in July 2026, aligns with .NET 10, and is supported through 14 November 2028. Microsoft says 1.6 "doesn't introduce major feature changes from IoT Edge 1.5 LTS, so upgrades are straightforward."

"Straightforward" is not the same as "automatic", though. For a minor-version jump such as 1.5 to 1.6, Microsoft's update guide describes a sequence rather than a package bump:

Stop IoT Edge on the device (sudo iotedge system stop) and uninstall it.
Upgrade the container engine (Docker or Moby).
Install the new IoT Edge. If you reuse an old configuration with iotedge config import, change the edgeAgent image in the generated /etc/aziot/config.toml to the 1.6 image.
In IoT Hub, update the deployment so it references the 1.6 edgeAgent and edgeHub images.
Start IoT Edge again with sudo iotedge config apply.

That is a hands-on change on each device, with a window in which the runtime is down. On a fleet you will want to script it, stage it and be able to roll it back.

Three related items share the same date and are easy to overlook:

Your own modules. If you wrote custom edge modules on .NET 8, they lose support on 10 November too, whatever IoT Edge version they run under.
EFLOW. Microsoft documents EFLOW 1.5 LTS (IoT Edge for Linux on Windows) as supported until November 2026, to match IoT Edge 1.5. If your gateways are Windows boxes running EFLOW, check the EFLOW release notes for the upgrade path before you plan the work, rather than assuming it matches the Linux procedure.
The host OS. Microsoft's 2026 end-of-servicing list puts Windows 11 IoT Enterprise, version 23H2, on the same date. A panel PC running 23H2 and EFLOW 1.5 has two things expiring on one day.

Why edge runtimes go stale

There is a pattern behind both changes, and it is worth naming because it will come round again: 1.6 has its own end date in November 2028.

An edge runtime's life is tied to things you don't control. Greengrass V1 depended on a cloud control plane, and when that plane was switched off, the runtime's purpose went with it. IoT Edge depends on a language runtime's support calendar, so its date was set the day Microsoft picked .NET 8. Your own product roadmap fixes neither date.

Meanwhile the devices are usually the hardest part of the estate to touch. They sit behind customer firewalls, have limited bandwidth, need a site visit when an update fails, and are often owned by an operations team rather than the engineers who chose the runtime. That combination is how a runtime with a three-year warning still catches people out.

This month's drill

If you run either runtime anywhere, here is what I'd do before 10 November.

1. Get a real inventory, not a remembered one. Ask the devices, not the spreadsheet. For IoT Edge, iotedge version on the device reports the security subsystem version, and iotedge logs edgeAgent / iotedge logs edgeHub show the runtime module versions. Compare those with what your IoT Hub deployment manifests reference. For Greengrass, list every device that ever ran a V1 core and confirm whether it has been rebuilt on V2. Include the test rigs, demo units and the one at the customer who never upgrades.

2. Classify each device. For each one, write down: runtime and version, host OS and version, any custom modules and their language runtime, who can physically reach it, and what stops working on site if it goes offline for an hour. That last column decides your rollout order.

3. If V1 cores are still running, triage them first. They are already past the date. Decide per site whether to rebuild on Greengrass V2 or move off Greengrass entirely. AWS is clear that V1 over-the-air updates "can't upgrade core devices from V1 to V2", so this is a reinstall, not an update. AWS offers two V2 runtimes. The full Greengrass nucleus lets you import V1 Lambda functions as Lambda components and supports the local shadow service, client devices and connectors. Nucleus lite suits constrained devices but requires rewriting Lambdas as generic components and drops those three features. Pick per device class, not per fleet.

4. Rehearse the IoT Edge 1.5 → 1.6 upgrade on one device, end to end. Use the full sequence above, not just the package step. Time it. Check what happens to messages produced while the runtime is down: does edgeHub's store-and-forward cover the gap, or do upstream sensors buffer and replay? Then run sudo iotedge check --verbose and confirm the edgeAgent/edgeHub image versions match the security subsystem's major and minor version.

5. Pin your images. Microsoft's guidance is to use specific tags (such as 1.6.1) in production and keep rolling tags (such as 1.6) for development. A pinned tag means a deliberate change you can roll back. A rolling tag means whatever happens to be pulled next time a container restarts.

6. Write the rollback down before you need it. For each device class, decide what "back out" means once the old version is out of support. Often the honest answer is "fix forward", in which case you need a recovery image and a way to reach the device that doesn't depend on the runtime you just broke.

7. Put the next date in the calendar now. IoT Edge 1.6 LTS ends on 14 November 2028. Microsoft says each new LTS is "planned to ship about six months before the prior LTS reaches end of support." Record both dates in whatever your team actually reads, and give the line an owner.

The decision behind the checklist

The checklist covers the next few weeks. The bigger question is whether you want your edge layer's life cycle set by someone else's calendar.

Sometimes the answer is yes. A managed runtime gives you deployment, identity and fleet tooling you would otherwise build yourself, and an end date every two or three years is a fair price. But make that a deliberate choice, recorded in an architecture decision record alongside the alternatives you considered: a plain container host with your own deployment pipeline, a broker-centred design using open MQTT, or a different vendor's runtime. If the record also names who watches the lifecycle pages and how long a fleet-wide upgrade takes, the next end-of-support notice becomes a planned job rather than a scramble.

Sources

If you're not sure what's actually running on your gateways, a two-week discovery and audit sprint turns that into an inventory and an upgrade plan: book a discovery call.