US breaches average $10.22M. For banks and insurers, mainframe vulnerability management on z/OS closes the gaps scanners miss and neutralizes the data itself.
Mainframe vulnerability management is the continuous discipline of locating, assessing, prioritizing, and remediating security weaknesses on IBM Z and the z/OS operating system.
It applies the standard vulnerability management cycle — discover, identify, assess, remediate, verify — to a platform with its own rules: vulnerabilities hide in security-software configurations and in privileged code, fixes arrive on the vendor's schedule rather than a monthly patch cadence, and most enterprise scanners cannot see the platform at all.
The mainframe is engineered to be one of the most defensible platforms in the enterprise. That engineering does not make itself secure.
This guide covers the full mainframe vulnerability management program: the z/OS attack surface, how patching and scanning actually work, how to prioritize with current risk data, and the control every other guide leaves out — making the data itself worthless to an attacker even when a vulnerability slips through.
For the broader picture, our mainframe security pillar maps how each control fits together.
Two beliefs about mainframe security are both correct.
The platform is secure by design, but it is still vulnerable in practice. Logical partition isolation, hardware cryptography, and mature access-control software give the mainframe defences few distributed systems can match.
Permissive default configurations, aging cryptographic algorithms, lagging adoption of multi-factor authentication, and siloed logging leave real gaps that attackers can exploit, which is why agentless mainframe security approaches have gained ground.
The cost of getting this wrong has consequences for the bottom line; for example, IBM's 2025 Cost of a Data Breach Report puts the global average breach at $4.44 million, while the United States average reached a record $10.22 million.
Financial services averaged $5.56 million and healthcare $7.42 million — i.e., the two industries most dependent on the mainframe as a system of record. These figures rank among the leading data breach risks facing regulated enterprises.
The same report found the average breach took 241 days to identify and contain, a nine-year low driven by faster detection. The mainframe complicates that math because integration with cloud services and application programming interfaces (APIs) has widened its attack surface well beyond the era when mainframe modernization meant terminal emulation alone.
Mainframe integrity concerns the correctness and consistency of your data and the system's logical soundness. Mainframe security is about protecting that system and data from threats.
Vulnerability management falls within the security half of that pairing, and our mainframe security solutions guide treats both halves as a single resilient whole.
Mainframe vulnerability management runs as a continuous loop, with phases being:
Each phase carries platform-specific weight that the mainframe security tools you choose must account for.
Asset discovery comes first because you cannot protect what you have not inventoried. That means cataloguing logical partitions, subsystems, connected applications, and the data stores they touch, then keeping the inventory current as the environment changes. Skipping this step is how unmanaged exposures accumulate inside a practical z/OS security program.
Prioritization is where mainframe programs separate from generic ones. Because the platform hosts mission-critical data, ranking findings by real-world risk matters more than counting them, and that ranking feeds directly into the remediation choices a sound set of data security best practices demands.
The sections below break down identification, prioritization, and remediation in detail.
Mainframe vulnerabilities fall into two families, and most programs over-invest in one while underestimating the other.
Configuration flaws are usually resolved by a skilled administrator changing settings, tightening access, or disabling an unused service. Code-based flaws require specialized developers and deeper scanning to find and close, which is why they are easier to ignore, and why a data-layer control that blunts the impact of any single flaw belongs in the program.
Configuration issues receive the bulk of attention and budget, partly because they are more visible and partly because the consequences of code-based vulnerabilities are underestimated.
That imbalance is a mistake. A privileged code path that lets an attacker escalate access can do more damage than a single misconfiguration, so both belong in scope from day one of any z/OS security controls program.
Securing the mainframe starts with knowing where it can be attacked. Access on z/OS is governed by an External Security Manager (ESM), and the choice of ESM shapes the rest of your z/OS security controls.
The three most commonly used are IBM's Resource Access Control Facility (RACF), Broadcom's CA ACF2 (Access Control Facility 2), and CA Top Secret, often supplemented by Vanguard tooling for administration and assessment.
Beyond the ESM, the attack surface includes Authorized Program Facility (APF) libraries, supervisor calls, and Unix System Services (USS), the Unix environment embedded in z/OS.
APF-authorized code runs with elevated privilege, so a flaw there is high-value to an attacker, while permissive RACF defaults and exposed USS paths introduce familiar Unix risks onto the platform. These are precisely the areas a generic scanner overlooks, and a proper mainframe security stack is built to inspect.
Legacy protocols round out the picture. File Transfer Protocol (FTP) and TN3270 terminal access often remain enabled long after they are needed, and weak access control settings turn them into open doors.
The most common real-world findings are configuration weaknesses in exactly these places, which is why pairing tight access control with strong mainframe encryption is the baseline expectation.
Mainframe patch management does not follow the predictable monthly rhythm of distributed IT.
There is no Patch Tuesday. Instead, vendors issue advisories through their security teams, and fixes arrive as Program Temporary Fixes (PTFs) tied to an Authorized Program Analysis Report (APAR), applied through System Modification Program/Extended (SMP/E).
Each step must be tested in a controlled environment before production, a discipline the mainframe security software market is built around.
Patch management is the act of applying those PTFs and updates to close known flaws.
Vulnerability management is the larger discipline that decides which flaws matter, in what order, and whether a patch, a configuration change, or a compensating control is the right response.
Patch management is one phase of mainframe vulnerability management, not a synonym for it, and the mainframe security solutions you deploy should treat it as such.
The practical consequence is timing risk. Because mainframe fixes require careful testing and scheduling, the gap between a vulnerability becoming known and a patch reaching production can be long, and that window is exactly where data-layer protection earns its place.
Vulnerability scanning and penetration testing answer different questions, and compliance frameworks generally require both as part of a mainframe vulnerability management program.
Scanning enumerates known weaknesses — i.e., outdated software, misconfigurations, missing controls — continuously and at scale. Penetration testing demonstrates how an attacker would chain those weaknesses into a working exploit, validating real-world impact.
A complete program runs both, and the mainframe security tools you adopt should natively support the scanning half.
Vendor scanning products such as Rocket's z/Assure Vulnerability Analysis Program and IBM's X-Force Red m-Ray target z/OS code and configuration directly, while specialist firms run mainframe penetration tests to prove exploitability.
Both have a role, and neither replaces the data-protection layer described later; therefore, data masking and tokenization sit alongside scanning rather than competing with it.
Scan continuously to find and close weaknesses, then conduct penetration tests periodically to confirm your defences hold up against an actual attack.
Scanning tells you what is wrong; testing tells you what an adversary could do with it — and your data protection for regulated industries determines how much that matters if they succeed.
Mainframe vulnerabilities are tracked as Common Vulnerabilities and Exposures (CVEs), the same way the rest of IT tracks them, but they are often buried in vendor-specific channels rather than surfaced in enterprise vulnerability platforms.
Vendors disclose them through Product Security Incident Response Teams (PSIRTs), which publish advisories that drive the PTF process. Pulling those disclosures into a unified view is a recurring gap that strong mainframe security software helps close.
Recent examples make the point that mainframe-connected components carry real CVEs. IBM disclosed CVE-2025-1000, a denial-of-service flaw in Db2 and Db2 Connect when connecting to a z/OS database due to improper handling of automatic client rerouting, which was scored 5.3 and was mitigated by an IBM interim fix.
The open-source Zowe framework inherited CVE-2025-41235, a high-severity (8.6) HTTP request-smuggling issue in Spring Cloud Gateway, which is used by its API Mediation Layer, and was fixed in the May 2025 Spring releases. Tracking exposures like these is part of any serious mainframe security solutions effort.
Prioritization should use two scores together, not one in isolation.
The Common Vulnerability Scoring System (CVSS) rates a vulnerability's intrinsic severity, while the Exploit Prediction Scoring System (EPSS) estimates the probability it will actually be exploited.
A medium-CVSS flaw with a high EPSS score can outrank a high-CVSS flaw nobody is exploiting, and feeding both into your data security best practices produces a far sharper remediation queue.
Software bills of materials (SBOMs) add a third input by exposing the open-source components — such as the Spring library above — hidden within mainframe products.
Here is what most security teams miss: the vulnerability management tools protecting the rest of the enterprise are effectively blind to the mainframe.
Products built for distributed environments — the well-known scanners that cover servers, endpoints, and cloud workloads — have little to no z/OS coverage because they were never designed for the platform.
That blind spot sits directly over the systems holding the most sensitive data, a problem on-premises data security planning has to confront head-on.
The instinct is to close the gap by installing a mainframe agent for scanning or protection.
That instinct carries its own cost. Every agent added to the mainframe is new code on your most critical platform, with the potential to consume capacity, complicate change management, and destabilize legacy applications, which is the case for agentless mainframe security instead.
The more durable answer treats scanner coverage as necessary but not sufficient.
A control that protects the data itself — through tokenization or dynamic data masking — closes the exposure regardless of whether any scanner ever sees the underlying flaw, and that is the shift the next section describes.
Vulnerability management is a detect-and-remediate discipline. It finds weaknesses and helps you fix them, but it cannot protect data during the window between a vulnerability becoming known and a patch reaching production, and it does nothing when a scanner never fires because an attacker is using stolen but legitimate privileged credentials. This is the gap that data tokenization is built to close.
Format-preserving tokenization replaces a sensitive value, such as a credit card number, with a token that has no mathematical relationship to the original while keeping the format intact, so mainframe applications continue to work without code changes.
An attacker who reaches a tokenized system finds worthless substitute values, which is a stronger position than tokenization versus encryption framing alone conveys.
This is where the difference between tokenization and encryption matters most.
Two properties make this approach specifically fit the mainframe.
It is agentless and in-line, meaning there are no application code changes on the mainframe because the control operates in the network traffic flow rather than on z/OS itself.
It also moves protection ahead of any breach — the data is neutralized before an attacker can access it — and because vaulted tokens bear no mathematical relationship to the original, the approach better withstands the future threat of quantum decryption than format-preserving encryption does.
Mainframe vulnerability management maps to a stack of regulations, each with a different emphasis.
The Payment Card Industry Data Security Standard (PCI DSS) 4.0 focuses on protecting cardholder data, the Digital Operational Resilience Act (DORA) emphasizes operational resilience and third-party oversight, and New York's 23 NYCRR Part 500 centers on cybersecurity governance led by a chief information security officer.
Frameworks from the National Institute of Standards and Technology (NIST), along with HIPAA and the General Data Protection Regulation (GDPR), impose additional requirements that shape how regulated firms approach data protection in regulated industries.
Tokenization changes the compliance math in a way scanning cannot.
By removing live primary account numbers (PANs) from the mainframe environment and replacing them with tokens, you reduce the number of systems and controls within the audit boundary, which is at the core of how PCI tokenization simplifies compliance. Fewer in-scope systems means a smaller attack surface to manage and a shorter, less costly audit.
With financial services breaches averaging $5.56 million and healthcare $7.42 million in IBM's 2025 report, reducing both the data exposed and the systems in scope addresses cost and compliance at once.
Teams working toward 4.0 readiness can map their controls against our PCI DSS 4.0 tokenization requirements checklist, and insurers carrying similar obligations can start with mainframe security for insurers.
Mature programs move from periodic, severity-only scanning to continuous, risk-based prioritization. Instead of treating every high-CVSS finding as equally urgent, risk-based vulnerability management weighs severity, exploit probability, and business context together, so remediation effort lands where actual risk is highest.
This is the same prioritization logic that underpins data-centric zero trust.
The progression is worth naming so you can place your own program on it. Many organizations start with ad hoc scanning, then move to scheduled scanning, then to continuous monitoring, and finally to risk-based remediation paired with data neutralization.
Each step reduces exposure, and the final step is where a vulnerability's existence ceases to be a data-breach event, anchored in disciplined data security best practices.
A working mainframe vulnerability management program is a sequence of concrete steps. The list below mirrors the structure of a conventional program and adds the data-layer step that most omit, building on the foundations of our mainframe security pillar.
Catalogue every partition, subsystem, application, and data store, and keep the inventory up to date. A baseline turns later scans into meaningful comparisons rather than isolated snapshots, and it is the first defence against the leading data breach risks.
Run scanning that covers configuration weaknesses and code-based flaws, because a program that checks only one family leaves the other open. The right tooling, surveyed in our mainframe modernization guidance, inspects both.
Rank findings by severity, exploit probability, and the criticality of the affected system. This risk-based approach keeps your team working on real risk instead of raw finding counts, the same logic behind data-centric zero trust.
Apply vendor PTFs through SMP/E after controlled testing, and harden configurations where a patch is not the right fix. Effective patch management means some exposures are best closed by tightening settings — an access change or stronger mainframe encryption — rather than waiting on a fix.
Validate your defences with periodic penetration testing on critical environments using purpose-built mainframe security tools. Scanning finds weaknesses; testing proves whether they can be exploited before they widen your attack surface into a breach.
Apply the principle of least privilege (PoLP), review RACF and ACF2 permissions regularly, and deploy multi-factor authentication on z/OS, removing standing permissions that attackers exploit. Tight access control is among the most effective steps available.
Track and update open-source software on the mainframe, apply patch management for known CVEs, and use SBOMs to see what is actually inside your products. Frameworks like Zowe carry the same component risk as any modern stack, which the mainframe modernization path has to plan for.
Tokenize sensitive fields so that a successful exploit yields worthless tokens rather than usable data. This is the step that turns a breach of the system into a non-event for the data, and it is the core of in-line data tokenization.
Forward System Management Facilities records to your security information and event management (SIEM) platform so mainframe activity is visible alongside the rest of the enterprise, complementing the access control layer. Isolated logs are a recurring weakness.
Align your controls with PCI DSS, DORA, NIST, and other applicable frameworks — PCI tokenization can simplify compliance here — and automate reporting to stay continuously audit-ready, rather than scrambling before each assessment.
The tooling market spans several categories, and a defence-in-depth program usually combines them. For configuration auditing and compliance checking, IBM's zSecure Audit and BMC's AMI Command Center for Security manage and verify security settings across partitions.
For data activity monitoring, IBM Security Guardium for z/OS records who accessed what data and when, complementing the tokenization versus encryption decision at the data layer.
Access control and scanning come from a familiar set of vendors. RACF, CA ACF2, and CA Top Secret govern access, Rocket's z/Assure Vulnerability Analysis Program scans z/OS code and configuration, and Vanguard provides assessment and administration tooling.
Many of these enforce access well but leave the data live, a limitation that data masking and tokenization address directly.
What this market underserves is the data layer. Most tools detect, monitor, or control access, but they leave the data live and exposed once access is granted, which is precisely the role an independent, agentless tokenization control fills as a distinct layer in a defence-in-depth design.
Understanding where each option fits starts with understanding the differences among tokenization, encryption, and masking.
Mainframe vulnerability management finds and fixes the weaknesses. It cannot guarantee that every weakness is closed before an attacker reaches it, which is why the data itself needs protection that does not depend on perfect patching.
DataStealth closes that gap at the data protection layer:
See how it fits your environment on the DataStealth data protection platform page, or request a demo →
Bilal is the Content Strategist at DataStealth. He's a recognized defence and security analyst who's researching the growing importance of cybersecurity and data protection in enterprise-sized organizations.
