8 min read
A CISO receives an early-morning alert about a newly disclosed CVE affecting a widely deployed component of the IT estate. The advisory specifies which versions are affected. The questions that follow are, in principle, simple: How many of our systems does that component run on? In which versions? Where have we already applied the patch?
In the distributed estate, the answers exist within minutes. A query against the configuration management database, an agent push from Tanium1 or SCCM, a dashboard view from ServiceNow Discovery, and the CISO has a list of affected hosts, their current state, and the residual exposure.
On the mainframe estate, the same question takes a different shape. A request reaches the systems team. The systems team logs into each LPAR. Commands are run, output is captured, results are aggregated by hand. With ten LPARs and an experienced team, the answer can typically be assembled within hours. With eighty LPARs across multiple sites, frequent maintenance windows and several technical owners, it can take considerably longer — in practice, often days — and the result is sometimes partial.
The question "which version of z/OS is running on which LPAR, with which PTFs applied" should, in theory, take seconds. In practice, in many mainframe environments, gathering a reliable answer can take considerably longer - often extending to hours, depending on the number of LPARs and the maturity of existing tooling.
The reasons are largely cultural. The mainframe industry has cultivated, over five decades, a model in which each LPAR is treated as a unit in itself. Stability is prioritised over uniformity. The same z/OS2 release runs in slightly different configurations across instances to match local workload and local operational patterns established by the engineers who have operated those LPARs for years. Cross-LPAR queries have been possible but rarely automated, because automating them has competed unsuccessfully against the workload of keeping each LPAR running.
The result is a parc whose state at any given moment is known mainly to the people who operate it directly. There is no equivalent of a central inventory dashboard updated continuously by agents reporting in from every node. There is a network of engineers carrying detailed mental maps of their own LPARs, supplemented by spreadsheets that are accurate at the moment they are produced and out of date within hours.
For decades, this was tolerable. The pace of change was slow. Patch cycles were quarterly. The number of LPARs in a typical environment was manageable by a few senior engineers. That has stopped being the case.
In 2026, large IBM Z customers operate dozens of LPARs per site, with the largest banking and insurance environments running well over a hundred. Maintenance cycles have shortened. Security patches arrive monthly, sometimes more often. Compliance audits ask, with increasing precision, the exact state of every system at every moment.
When the inventory state is not known with confidence, three operational costs accumulate.
The first is delayed patching. A patch cannot be safely deployed without first knowing where it needs to go and what state the target systems are in. The longer it takes to assemble that knowledge, the longer the window between vulnerability disclosure and patch application.
The second is failed audits. External auditors and internal compliance teams increasingly require traceable evidence that maintenance has been applied uniformly. A declaration from a systems engineer that "all production LPARs are at the current maintenance level" has stopped being sufficient where regulation demands documented proof. The cost of producing that proof manually, across a hundred LPARs, is measured in person-weeks per quarter.
The third is risk concentration. When inventory knowledge sits in the heads of a small number of senior engineers, the organisation acquires a dependency on their availability. Each departure, each vacation, each change of role creates a temporary blind spot whose duration depends on how thoroughly the engineer documented their environment before stepping away.
That dependency compounds a broader mainframe skills gap, examined in Knowing the Components Is Not the Same as Understanding the System .
| ~15s |
Tanium's architecture is built to query an entire enterprise fleet within 15 seconds - a capability the company reports scaling to customer deployments of more than 500,000 endpoints. |
The obvious response to the inventory problem is to deploy, on the mainframe, the kind of agent-based estate management that has worked elsewhere for two decades. In practice, that response has taken hold on z/OS only rarely because, for years, it was never quite the need. Mainframe environments have historically prioritised stability and predictable workload over continuous polling. That has started to change: a genuine need for this kind of visibility has emerged in recent years, and any monitoring approach introduced onto the platform now has to earn its place against a strict cost/performance trade-off, with the value of the information it produces clearly outweighing the resources it consumes. Three design principles follow from that trade-off.
The first is minimal RACF privilege. Mainframe security models grant access to identities, not to processes, so the question is how much access a monitoring identity actually needs. In practice, the lowest possible level suffices: READ access to the datasets, libraries and configuration files it inspects, and nothing more. Scoped this way, under its own dedicated identity, the process is not the broad, intrusive agent that mainframe teams have historically been wary of — its footprint on the access model is deliberately kept as small as the task allows.
The second is resource discipline. Mainframe transaction systems run with extreme attention to predictable response times, so continuously polling live system state, in the way distributed-estate agents do, is not an option: even a small, constant draw on CPU and I/O is operationally significant on a platform engineered for stability above all. The answer is not to give up visibility, but to find the right compromise between reliability and consumption. In practice, that means running a full discovery rarely - for instance once a week or once a month - and relying on lightweight delta discovery the rest of the time: rather than reading the content of every file, the process checks indicators such as a file's size and its position to detect that something has changed. It does not determine which line was modified - identifying that level of detail would itself consume too many resources - it simply reports that a given file changed, and when. That is enough to trigger an alert and a targeted investigation, without asking the platform to sustain a continuously invasive process.
The third is the lesson of SolarWinds. Distributed management agents have proven to be high-value supply chain attack vectors, and the mainframe community has watched SolarWinds and its successors play out across the rest of the IT estate. The lesson is not that third-party software has no place on z/OS — mainframe shops have run vendor-supplied security and compliance products under RACF's own controls for decades. The lesson is that the bar for admitting one has to be set accordingly: a track record built specifically on z/OS and RACF, not adapted from distributed-IT practice, and a demonstrated ability to operate within the platform's own security model rather than around it.
Each of these is a real design constraint, not an insurmountable one. None of them, individually, makes mainframe-side inventory automation impossible. Together, they explain why continuous inventory on z/OS has taken a different technical path from its distributed equivalent, and why a workable solution has to satisfy all three at once — minimal privilege, minimal consumption, and no reliance on third-party software.
It is worth being precise about what these three constraints rule out. They describe the risk profile of transplanting a distributed-IT polling agent onto z/OS unchanged: a new process, requesting broad access it did not previously have, actively querying live system state at intervals. Monitoring built on native z/OS constructs — a started task running under its own scoped RACF identity, consuming data the system already produces (such as SMF records) rather than actively polling for it — sits in a different part of that risk space. It is not risk-free, and it does not eliminate the need for RACF governance or for the started task's own footprint to be sized correctly. But it is a different architecture from the one the three constraints above describe, and the distinction matters when evaluating a specific product against them.
The regulatory framework has shifted faster than the operational practice.
DORA3 Article 9.2 requires financial entities to maintain high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use, or in transit, and Article 9.4 requires documented policies and controls for ICT change management. Both formulations imply, in practice, that the financial entity can produce evidence of the state of its systems at any given moment.
We've examined what DORA's demand for demonstrable resilience means for mainframe access architecture more broadly in DORA and Mainframe Access: The Security Gap Nobody Is Watching.
PCI DSS 4.04, applicable to any environment processing payment card data, requires that all system components be inventoried (Requirement 12.5.1) and that critical or high-severity patches be applied within prescribed windows (Requirement 6.3.3). Where these requirements apply to mainframe components, the absence of continuous inventory and patch state visibility is a control gap that auditors are increasingly trained to identify.
ISAE 3402 and SOC 1 audits, used for service organisations that include large mainframe operators, require that controls be both designed and operating effectively. Operating effectively, in this context, means traceable, repeatable, and producing evidence on demand.
The shared assumption across all three frameworks is that the operator of the system can answer, with documentary proof, what is running where. The cost of being unable to do so has moved from operational inconvenience to compliance exposure.
|
In environments I have operated, the difference between "We have applied the fix" and "we can prove we applied it on every LPAR" are two different statements. The gap between them used to be an operational detail. Regulation has turned it into a finding. - Sebastian Dewar, CTO, Virtel |
Adopting a continuous inventory discipline on the mainframe is, in 2026, less a technical exercise than an organisational one. The tooling has matured. What has been slower to change is the assumption that inventory is something the systems team handles when they have time, against the actual workload of operating production.
The shift that succeeds, in environments that have made it, has three components.
The first is acceptance that inventory is a compliance function as much as an operational one. Treating it as a side activity competes against urgent operational work and loses. Treating it as a primary deliverable, with reporting lines into compliance and audit, gives it a budget category that operational backlog does not have.
The second is integration into the existing audit and observability pipelines. Inventory data that lives in a separate tool, accessed only by systems engineers, perpetuates the silo that the discipline is trying to break. Inventory data that flows into the same dashboards used by the rest of the IT operation, even at summary level, makes the mainframe state visible to people whose decisions depend on knowing it.
The third is operational rehearsal. Knowing the state of the parc is necessary but not sufficient. The patch application and rollback procedures that depend on that knowledge need to be exercised regularly enough that the team can execute them under pressure.
The question "what are you actually running" was, for forty years, a question that mainframe environments could afford to answer slowly. The regulatory and threat environment of 2026 has stopped giving them that time. The shift from periodic to continuous inventory is overdue. The technology to make that shift exists, has matured, and is deployable today.
Vanguard SAMM, solution distributed by Virtel
Bring continuous inventory discipline to your mainframe estate.
Vanguard SAMM (Software Application Monitoring and Malware Detection) provides continuous validation of maintenance levels across all LPARs and systems, with a web-enabled centralised interface and real-time alerting. It addresses the operational requirement to know, at any moment, which software versions are deployed on each LPAR, which fixes have been applied, and where the parc deviates from baseline.
SOURCES and REFERENCES