Reliability After the 7.6 Cutoff: Why Asset Health and the Integration Layer Are Now Your Problem

The Maximo 7.6.1.x support entitlement ended on September 30, 2026. For the reliability organisation, that date does not announce itself as an outage. It announces itself as a change in who owns the answer.

Reliability work has always depended on a chain of dependencies that individually look mundane and collectively decide whether an asset-health program functions. A condition-monitoring feed writes into an IoT platform. The IoT platform passes readings into the asset management system. The asset management system applies the asset-health scoring, converts a score into a degradation curve, and turns a curve into a work-request recommendation. A planner accepts the recommendation. A technician executes the work. A failure record feeds back and the model learns. Every link in that chain is a system boundary, and every system boundary is a place where a support entitlement either exists or does not.

After October 1, several of those links sit on the wrong side of the entitlement line for a large population of estates. The reliability organisation did not choose that. It inherited it from the platform decision made years earlier. But the reliability organisation is the function that will be measured on whether the asset-health program keeps producing usable recommendations, regardless of who owns the platform. That is the uncomfortable reality of post-entitlement reliability work: the accountability and the control have come apart.

This is the second of the two failure surfaces created by the deadline. The first is field mobility, where the risk is operational and immediate. Reliability is different. Its risks accumulate more slowly and show up later, which makes them easier to defer and more expensive to defer. An asset-health model that quietly degrades over two quarters does not produce a crisis. It produces a series of decisions made on slightly wrong data, and the cost is invisible until an asset fails that the model should have flagged.

This article is about that surface. It covers why asset health is now the reliability organisation's own problem, what the September security patch train reveals about the integration layer underneath it, how to read the boundary of responsibility that the deadline has redrawn, and how to build a reliability risk register that reflects what actually changed.

Why Asset Health Becomes the Organization's Own Problem

Asset health is not a feature. It is an inference. The Maximo Health line, the condition-monitoring pipeline, and the predictive models that sit on top of them are all producing an estimate of asset condition from data that arrives through a chain of integrations. The value of that estimate depends entirely on the integrity of the chain, and the chain is precisely what an unsupported estate can no longer get a vendor fix for.

Consider what a degradation in that chain looks like in practice. A sensor gateway drops a reading. The IoT platform records a gap. The asset management system interpolates through the gap rather than flagging it. The asset-health score drifts slightly. The work recommendation is generated a few days late or not at all. Nobody notices, because a slightly late recommendation looks like normal variance in the reliability program. Multiply that across a fleet and a quarter and the program quietly shifts from predictive to reactive without anyone changing a policy.

During supported operation, a defect that produced this behavior would be filed and fixed. In the post-entitlement period, the behavior is the organisation's to diagnose and remediate. Reliability engineers are often the first people to notice it, because they are the ones looking at the recommendation quality, but they are rarely the ones who own the platform change that would fix it. That gap between detection and authority is the first structural problem the deadline creates.

The second structural problem is subtler and more dangerous. Reliability organizations measure the health of the program, not the health of the plumbing. A monthly reliability review looks at unplanned downtime, work-request quality, and model accuracy. It almost never looks at integration throughput, message drop rates, or credential expiry. When the plumbing starts to fail, the first symptom appears in the metrics the reliability team owns, but the cause lives in a layer the reliability team does not monitor. The diagnosis takes a full review cycle, and by then the degradation has a quarter of history behind it.

The practical implication is that post-entitlement reliability work requires the reliability organisation to extend its monitoring up the stack. Not to own the integration layer, but to instrument the health of the boundary between the layers. A reliability program that measures only its own outputs will keep producing a clean-looking dashboard while the inputs rot underneath it.

What the September Patch Train Tells Us About the Boundary

The most instructive event of the last cycle for reliability organizations is one that arrived as a security story. A national CERT advisory published on September 23, 2026 consolidated twelve vulnerabilities across IBM MQ, IBM MQ Appliance, and the Langflow open-source project. Three of the Langflow flaws are unauthenticated at a CVSS rating of 9.8, involving code injection and OS command injection with arbitrary code or OS-command execution. A separate cluster covers IBM MQ, including a CVSS 10.0 pre-authentication heap buffer overflow and a CVSS 9.9 heap underflow.

Read that advisory as a reliability engineer rather than a security engineer, and a different lesson appears. Every one of those components is a message-passing or orchestration layer. They are the pipes that carry data between systems. MQ is the transport that moves integration messages between Maximo and the systems around it. Langflow is an orchestration surface increasingly used to wire together AI and data workflows. When a flaw lands in a message transport, the reliability consequence is not only the security exposure. It is the patching requirement, the restart, the version verification, and the window of restricted reachability that the remediation demands.

That requirement lands on the reliability organisation as an availability event. A patch to a message transport means a maintenance window, and a maintenance window means an interruption in the condition-monitoring pipeline. The organisation that has not designed its reliability program to tolerate an integration restart will discover that the pipeline does not resume cleanly, that some in-flight messages are lost, and that the asset-health scores on the far side have a gap they quietly interpolate over. The security advisory is the visible event. The reliability consequence is the invisible one.

The version tables published with the advisory make the boundary concrete. The remediation requires a specific fixed build for each affected line, and the sequence recommended by the analysts covering it is patch and rotate: upgrade, verify the running version after the upgrade, restrict reachability until rollout completes, isolate the affected host from unnecessary secrets, and rotate the provider keys stored in the platform after the patch. That last step, rotating keys, is the one most relevant to reliability teams, because a key rotation on an integration host is exactly the kind of change that breaks a pipeline two days later when the pipeline's own credential has not been rotated to match.

There is a third lesson in the advisory, and it concerns responsibility. The flaws are in IBM products and in an open-source project. The fix is vendor-provided. But the decision to apply the fix, the maintenance window, the reachability restriction, and the key rotation are all the organisation's. The security boundary is maintained by the vendor. The operational boundary is maintained by the estate. Reliability works in the second boundary, and the deadline did not change who carries that work. It only removed the vendor's share of the safety net below it.

The Responsibility Line the Deadline Redrew

The most useful thing a reliability organisation can do in the post-entitlement period is to draw an explicit line between what the vendor now maintains and what the estate now maintains. Most estates have never written that line down, because during supported operation the distinction rarely mattered. Now it does, and the line is not where most teams assume.

The vendor continues to maintain the supported product lines: the MAS platform, Maximo Health on the current line, the supported mobile client, and the components covered by an active maintenance contract. Fixes for defects in those components continue to flow.

The estate now maintains everything that sits between supported products. That includes the custom integrations that move condition data from sensors to the IoT platform to the asset management system. It includes the automation scripts that transform and route that data. It includes the credentials, certificates, and key material that authenticate each hop. It includes the monitoring that would detect a silent failure in any of those hops. And it includes the reconciliation logic that decides what to do when a reading does not arrive.

The reason that line matters is that reliability work crosses it constantly without anyone noticing. A reliability engineer tuning a model is working in the vendor-maintained layer. The same engineer investigating why a reading did not arrive is working in the estate-maintained layer. The skills are adjacent but not identical. The escalation paths are completely different. During supported operation, both paths could sometimes end at the vendor, so the distinction stayed blurry. Post-entitlement, the estate-maintained path ends at the estate, full stop.

A second, less obvious part of the line concerns data quality. The vendor maintains the model. The estate maintains the data the model consumes. Asset health is only as good as the condition data feeding it, and that data crosses every estate-maintained boundary on its way in. A model maintained by a fully supported vendor will still produce bad recommendations if the estate is feeding it data through an integration that the estate no longer monitors. The deadline did not weaken the model. It weakened the model's inputs, and it moved the responsibility for those inputs entirely onto the organisation.

Building a Post-Entitlement Reliability Risk Register

The deliverable that converts all of this from a concern into a plan is a reliability risk register. It should be short, specific, and owned. Four rows cover the surface for most estates.

The first row is silent pipeline degradation. The risk is that an integration between condition monitoring and asset management degrades without producing an error, and the degradation is detected only through the reliability metrics it corrupts. The controls are throughput monitoring on each integration hop, drop-rate alerts above a defined threshold, and a reconciliation check that compares expected reading volume against received volume on a daily cadence. The owner is the integration team, with a reliability team member accountable for the detection threshold.

The second row is patch-window availability. The risk is that a security or maintenance patch to a message transport or orchestration layer interrupts the pipeline and the pipeline does not resume cleanly. The controls are a tested restart procedure for each hop, a defined in-flight message handling policy, and a post-window reconciliation that confirms no gaps were introduced. This row is triggered by external events, so it should be reviewed whenever a relevant advisory is published.

The third row is credential and certificate drift. The risk is that a key rotation, certificate expiry, or credential change on one side of a boundary is not matched on the other, and the pipeline fails at the moment of the change. The controls are a consolidated inventory of every credential on every integration hop, a defined rotation procedure that sequences both sides, and an expiry calendar with lead-time alerts. This row is unglamorous and it is the single most common cause of post-entitlement pipeline outages.

The fourth row is model input integrity. The risk is that the asset-health model is producing recommendations from data that has drifted in quality, and the drift is invisible because the model itself is fully supported. The controls are input-quality metrics on the condition data, a periodic manual audit of a sample of recommendations against ground truth, and a defined threshold at which degraded input quality triggers a program review rather than a model review. The owner is the reliability team, because this row is the one the reliability team can actually control end to end.

Each row needs a named owner, a control set, and a review cadence. A register with rows but no owners is a document. A register with owners and cadences is a control.

Practical Implications

The reliability organisation cannot fix the platform decision that created this situation, and it should not try. What it can do is make its own surface resilient, and that work is concrete.

The first practical step is to map every integration hop between condition monitoring and asset management, and to confirm that each hop has throughput monitoring with an alert threshold. Most estates discover one or two hops that have no monitoring at all. Those hops are the highest-priority gap, because an unmonitored hop is a silent failure waiting to happen.

The second step is to build the credential inventory described in the third risk row. This is tedious work and it pays for itself the first time a rotation is performed without an outage. The inventory should include every credential, the systems on both sides of each boundary, and the rotation procedure for each.

The third step is to define the reconciliation check that compares expected condition-reading volume against received volume. This single control catches the majority of silent degradation events, and it is inexpensive to build once the hops are mapped.

The fourth step is to review the reliability risk register with the platform owner and the integration owner together, at least quarterly. The register crosses organisational boundaries by design, and a register reviewed only within one function will keep producing findings that no single function can act on. The review is where the ownership gaps get resolved.

Finally, the reliability organisation should treat external security advisories as reliability events, not as someone else's queue. When a message transport or orchestration layer is patched, the reliability program has an availability exposure, and it should be represented in the patch planning from the start rather than informed afterward.

Bottom Line

Nothing broke on October 1. The asset-health program is still producing recommendations, the pipeline is still moving condition data, and the reliability metrics still look broadly normal. That is exactly why this period is dangerous. The failures that a support entitlement prevented do not announce themselves on the day the entitlement ends. They appear months later, as a program that has quietly drifted from predictive to reactive.

The reliability organisation is where that drift will be detected, whether or not it owns the plumbing that causes it. The organisations that handle the post-entitlement period well will draw an explicit line between vendor-maintained and estate-maintained components, instrument the boundaries rather than only the outputs, treat the September patch train as a template for how integration-layer work becomes reliability work, and run a short, owned risk register that turns a diffuse concern into four rows with names against them. The accountability arrived on October 1. The control has to be built.