Compare how z/OS and VSEⁿ handle access control, threat detection, and cyber recovery – and what those differences mean for your workloads.
A fair comparison of z/OS vs. VSEⁿ security starts with business requirements, operational risks, and recovery needs.
Anyone looking into cybersecurity on IBM Z today will almost inevitably talk about z/OS. The operating system has a comprehensive security architecture, a broad range of specialized tools, and increasingly sophisticated capabilities for detecting suspicious activity and supporting recovery after cyberattacks. IBM has invested heavily in these areas over the past several years.
VSEⁿ, the successor to IBM z/VSE, now developed and maintained by 21st Century Software (21CS), receives considerably less attention. Yet companies running VSEⁿ also operate mission-critical applications, process sensitive information, and must meet requirements for data protection, access security, and recoverability.
Comparing the two operating systems therefore seems reasonable. The problem is that such comparisons can easily lead to the assumption that a larger portfolio of security products automatically translates into a more secure system.
I think that conclusion is too simplistic. The two operating systems have different architectural and operational philosophies, serve somewhat different audiences, and are often deployed under very different economic conditions. As a result, you can’t compare many of their security capabilities on a like-for-like basis.
At the same time, both platforms face certain fundamental security challenges. One of the most important is how an organization protects itself against a successful cyberattack and, more importantly, how it restores a trustworthy operational state afterward.
Two Operating Systems Designed for Different Purposes
z/OS is designed to handle large, complex, and often highly integrated enterprise workloads. Typical environments include extensive transaction processing systems, large database installations, and deeply interconnected batch and online applications. In many organizations, z/OS plays a central role in the overall IT architecture.
That naturally creates significant requirements for centralized administration, detailed logging, automated security controls, and integration with enterprise-wide security operations.
VSEⁿ has a different focus. The operating system primarily serves organizations that want to preserve and continue developing their existing VSE applications and the investments they have made in them. These are often mature, stable batch and OLTP environments that have evolved over decades, with well-understood business functions and technical dependencies.
However, it would be a mistake to associate VSEⁿ exclusively with small companies or less important workloads. Even large enterprises may depend on VSE applications for essential business processes. The size of an organization and the business importance of an application tell us very little about the operating system it runs on.
With VSEⁿ 6.4, released in October 2025, 21CS continued developing the platform, including improvements to cryptographic services, REST support for batch applications, and integration with modern development environments. The company’s product strategy also includes support for current IBM Z hardware. In July 2026, 21CS explicitly confirmed support for IBM z17 Single Frame and Rack Mount systems with appropriately updated VSEⁿ versions.
VSEⁿ is therefore an actively developed platform. The notion that it is merely an old operating system kept alive as long as possible does not reflect recent developments.
These different product strategies matter when comparing security capabilities. z/OS supports a very broad range of workloads and operational models. VSEⁿ focuses more specifically on maintaining and modernizing existing VSE environments. That leads to different expectations regarding functionality, administration, and integration.
An operating system should therefore be evaluated first against the security requirements of the environment where it is actually used.
Shared Hardware Doesn’t Mean Identical Security
Both operating systems benefit from the security architecture of modern IBM Z systems. This includes hardware-assisted cryptography, logical partition isolation, and various mechanisms designed to protect system integrity.
That shared foundation is a significant advantage. However, that doesn’t mean every security feature of a particular IBM Z generation can be used in exactly the same way by both operating systems.
Encryption provides a good example.
With DFSMS Data Set Encryption, z/OS offers a tightly integrated mechanism for encrypting supported VSAM and sequential data sets. Encryption is handled through the standard access methods, so applications generally do not need to be modified, provided the documented requirements are met. Cryptographic key access is controlled through ICSF and the associated security permissions.
VSEⁿ also provides cryptographic capabilities. These include Crypto Services, Encryption Facility for VSEⁿ, and the ability to use encryption features provided by the underlying storage infrastructure. How these mechanisms work together depends on the products involved, the data formats, and the individual installation.
The two approaches are therefore not functionally equivalent in every respect. A meaningful comparison must establish:
- Which data must be protected
- Whether encryption is required at the dataset or storage level
- How cryptographic keys are managed
For example, full storage encryption may satisfy certain requirements for protecting data at rest. However, it does not replace granular access control for individual files or cryptographic keys.
Conversely, even a highly granular encryption architecture offers limited value if key permissions are poorly controlled or administrative access is inadequately protected.
In practice, the overall security design quality makes the difference.
Access Control: Both Platforms Have a Solid Foundation
It would also be unfair to evaluate z/OS and VSEⁿ access security solely by counting the available products.
On z/OS, SAF and an external security manager such as RACF provide the foundation for access control. They allow highly detailed permissions to be defined for data sets, programs, system resources, and numerous other functions. Additional solutions support multi-factor authentication, privileged access management, and the monitoring of security-relevant changes.
The VSEⁿ security architecture builds on z/VSE’s established mechanisms. These include the Basic Security Manager, which supports user and resource protection and logs security-related events. You can also use external security products. For example, Broadcom continues to document the use of Top Secret for VSE in VSEⁿ environments.
This matters because VSEⁿ’s security capabilities are otherwise easy to underestimate.
Nevertheless, z/OS has a considerably broader ecosystem for integrating identity management, privileged access controls, multi-factor authentication, and automated security checks.
With VSEⁿ, it is important to examine:
- which requirements are handled by the operating system itself
- which are addressed by an external security manager
- which depend on infrastructure components outside the system
Also consider the different levels of environmental complexity. A clearly defined VSEⁿ installation with few communication paths may require less administrative effort than a large z/OS environment with numerous interfaces and different user populations.
However, lower complexity doesn’t guarantee better security. Once you introduce external APIs, web applications, database connections, or automated file transfers, additional attack paths emerge that you must address regardless of the operating system.
The Real Difference Becomes Clear in Threat Detection
To me, the comparison becomes particularly interesting when we move beyond traditional protection mechanisms.
A security system must first prevent unauthorized users from accessing sensitive resources. Things become more difficult when an attacker already has valid permissions, perhaps through compromised credentials.
Consider an application that regularly processes a large VSAM file. The associated batch user has all the permissions required to perform the job. One day, however, the same user ID is used to extract unusually large amounts of data or systematically modify records.
Traditional access controls may allow these operations because the user is technically authorized to perform them. The real problem is that the application’s behavior has changed.
This is exactly where IBM has significantly expanded its z/OS security portfolio in recent years.
Solutions such as IBM zSecure, including its current detection components, can monitor security events, analyze unusual data access patterns, and forward suspicious activity to higher-level security systems. Originally introduced through IBM Threat Detection for z/OS and now further developed as IBM zSecure Threat Intelligence, the approach uses techniques such as machine learning to identify unusual access patterns.
Integration with SIEM platforms lets you analyze mainframe events alongside information collected from other enterprise systems. This is particularly valuable for larger organizations whose Security Operations Centers need visibility across the entire IT environment.
VSEⁿ also supports security logging. Its BSM and ESM architecture provides information for audits and security analysis. The technical foundations are described extensively in the IBM Redbook Security on IBM z/VSE.
However, the publicly available product documentation does not currently establish an equally comprehensive, VSEⁿ-oriented solution portfolio for automatically detecting unusual file access patterns and responding immediately.
That certainly does not mean such capabilities are fundamentally impossible on VSEⁿ. External analytics, additional security products, and custom monitoring solutions can perform similar tasks.
The differences mainly lie in the scope of standardized, readily available solutions and the integration effort required.
“A poorly monitored z/OS installation isn’t automatically better protected than a carefully managed VSEⁿ environment simply because more security products are available.”
This is where z/OS has a clear advantage. That advantage becomes particularly relevant when organizations process very large data volumes, connect numerous applications, and need to detect suspicious activity as early as possible.
However, the advantage only materializes when organizations install the right tools, configure them properly, and integrate them into operational response procedures.
A poorly monitored z/OS installation isn’t automatically better protected than a carefully managed VSEⁿ environment simply because more security products are available.
Cyber Resilience Starts Where Traditional High Availability Ends
In my view, an even more important consideration is the distinction between cybersecurity and cyber resilience.
Mainframes have been regarded as exceptionally reliable platforms for decades. Redundant hardware, mature recovery procedures, and extensive data protection capabilities are key reasons they continue to support mission-critical workloads.
But high platform availability does not guarantee that data will remain intact and trustworthy after a successful cyberattack.
Let’s return to our VSAM file. An attacker modifies individual records over several hours. The application continues running, and the changes initially go unnoticed. Regular backups are also working exactly as intended.
The next morning, the business department discovers that customer data has been systematically manipulated.
From an infrastructure perspective, everything may have worked correctly. Yet the organization now faces a serious problem: Which backup still contains consistent, unmodified data? How can that be verified? And how can the affected information be restored without simultaneously losing legitimate business transactions processed in the meantime?
Traditional disaster recovery procedures are often insufficient in this situation.
Both operating systems share the ability to use appropriate functions provided by IBM storage infrastructure. These include IBM DS8000 Safeguarded Copy, which can create protected point-in-time copies that are not directly accessible from production systems.
21CS explicitly documents support for relevant storage capabilities in VSEⁿ. Version 6.4 also introduced improvements to certain console message handling functions associated with Safeguarded Copy.
For z/OS, IBM additionally provides a comprehensively documented solution architecture through IBM Z Cyber Vault. It combines protected backup copies, isolated recovery environments, validation processes, and automated recovery procedures. Depending on the configuration, the implementation may include GDPS and other specialized products.
That represents a significant difference in the scope of available solutions.
However, the comparison needs to remain fair. IBM Z Cyber Vault is an extensive architecture whose implementation requires investment in software, infrastructure, operations, and specialized expertise. Its capabilities should not simply be compared with the standard functions of an individual VSEⁿ installation.
Cyber recovery concepts can also be implemented for VSEⁿ. The relevant questions concern the storage and backup products being used, how recovery is organized, how data integrity is validated, and how applications are brought back into production.
The effort required to automate and validate these procedures may differ considerably.
A protected backup copy is not necessarily a verified, clean recovery point
That applies equally to both operating systems. For me, it is one of the most important principles of a modern cyber resilience strategy.
Security Capabilities Need Continuous Maintenance
Another issue often overlooked in security comparisons is the ongoing maintenance of the components involved.
With VSEⁿ 6.4, for example, 21CS moved its OpenSSL-based Crypto Services to the OpenSSL 3.0 family. At the time of release, that was an important modernization step. Since then, however, the OpenSSL 3.0 release family reached the end of its regular support period in September 2026.
This does not automatically imply a security vulnerability in VSEⁿ. What matters is the actual software level installed, including available PTFs, and how the vendor provides security fixes. Extended support arrangements or selectively backported fixes may also form part of an appropriate maintenance strategy.
Questions about current cryptographic libraries, supported encryption algorithms, and the handling of known vulnerabilities naturally apply to z/OS as well.
The continued development and maintenance of an operating system are therefore just as important as its original security architecture. Organizations planning to operate a platform for many years need reliable information about maintenance, security updates, and long-term product support.
For VSEⁿ, it is encouraging that 21CS continues to provide a long-term perspective through current releases and announced enhancements. However, for individual capabilities, such as the announced support for IBM Z Secure Boot, it remains important to distinguish between published development plans and functionality that has demonstrably been delivered.
What Does This Mean for DORA and Regulatory Requirements?
For regulated organizations, the ability to demonstrate cyber resilience is becoming increasingly important.
Since January 2025, the European Union’s Digital Operational Resilience Act (DORA) has established comprehensive requirements for ICT risk management, incident response, and the recoverability of mission-critical systems.
Neither z/OS nor VSEⁿ meets these requirements simply because an organization chooses that operating system. Organizations must demonstrate how they:
- Identify relevant risks
- Control access rights
- Detect security incidents
- Regularly verify the effectiveness of their recovery procedures
On z/OS, established tools support many of these tasks. They include solutions for automated compliance checking, security analytics, and preparing evidence for internal and external audits.
VSEⁿ operators can also meet the relevant requirements. Depending on the installation, they may need to use additional products, organizational controls, or custom-developed procedures.
These differences can show up in cost, the degree of automation, and the availability of specialized tools.
Even so, making a blanket statement about the regulatory suitability of either operating system would be unjustified. Regulatory obligations depend on an individual organization’s risks and critical business processes. Their implementation can only be properly assessed by examining the actual system environment.
Economics Belongs in the Security Discussion
One aspect deserves particular attention: Security must work reliably in day-to-day operations and remain economically sustainable.
z/OS has an extensive ecosystem for security management, threat detection, and cyber recovery. This creates significant technical opportunities, particularly for large and complex enterprise environments.
At the same time, these capabilities may add software licensing costs, operational overhead, and requirements for specialized personnel.
VSEⁿ takes a more focused approach. For organizations with clearly defined applications, manageable interfaces, and established operational practices, this approach may continue to make economic sense.
It would be difficult to justify requiring such an installation to implement exactly the same security infrastructure as a large z/OS environment with numerous interfaces and a 24/7 Security Operations Center.
That does not mean economic considerations should weaken fundamental security requirements. If a VSEⁿ application processes sensitive information and is mission-critical to the organization, its recoverability must be assured just as reliably as that of a comparable application running under z/OS.
The central economic question is therefore which security and resilience requirements must be met, and what it costs to satisfy them in a demonstrable and sustainable way within the respective environment.
In some cases, a relatively straightforward architecture may be sufficient. In others, a more extensive system with highly automated security monitoring may ultimately be the more economical choice.
z/OS vs. VSEⁿ Security: What a Fair Comparison Requires
If I were asked to evaluate both operating systems for cyber resilience, I wouldn’t start by listing every available security product. I would begin by defining specific attack scenarios and examining how each installation could handle them.
- What happens, for example, if the credentials of a privileged user are compromised?
- What options exist for detecting unusual access to mission-critical VSAM data?
- How quickly can the organization determine which information has been modified?
- Which protected backup copies are available, and how is their integrity verified?
It would be equally interesting to determine how long application recovery takes and how much data loss, if any, the organization would have to accept.
Such exercises could provide meaningful measurements of detection time, recovery duration, and acceptable data loss. The costs of the required security products and the effort involved in operating them should also be considered.
This type of evaluation would be far more informative than simply comparing product features.
The NIST Cybersecurity Framework 2.0, with its six functions—Govern, Identify, Protect, Detect, Respond, and Recover—would provide a suitable structure. It lets you assess security objectives consistently without making one operating system’s architecture the benchmark from the outset.
Two Viable Platforms, Different Capabilities
After reviewing the available technical documentation, I see a relatively clear picture, though it requires some nuance.
z/OS has a broader, more tightly integrated ecosystem for cybersecurity and cyber resilience. Particularly in automated threat detection, integration with enterprise-wide security operations, compliance automation, and orchestrated cyber recovery, mature solutions are available.
z/OS has a broader, more tightly integrated ecosystem for cybersecurity and cyber resilience. VSEⁿ, meanwhile, has an established security architecture and benefits from the IBM Z platform’s core strengths.
For organizations running large, complex, and highly interconnected mainframe environments, these capabilities represent a substantial advantage.
VSEⁿ, meanwhile, has an established security architecture and benefits from the IBM Z platform’s core strengths. With ongoing development by 21CS, support for current hardware, and modernization of cryptographic and communication components, it remains a relevant option for existing VSE workloads.
However, VSEⁿ operators more often need to determine which security monitoring and advanced cyber recovery capabilities must be provided through additional products or custom integrations.
These differences do not establish a universally valid ranking of actual system security.
The target audiences, technical requirements, and operational models differ too much for that. Furthermore, the security of any individual installation depends heavily on how consistently existing protection mechanisms are used, access rights are maintained, security events are monitored, and recovery procedures are tested.
The Fundamental Security Question
What I take away from this comparison is a fundamental question that every organization should be able to answer, regardless of its operating system:
After a successful cyberattack, can we demonstrate which data we can still trust, and can we restore our mission-critical applications within the required timeframe?
An organization that can answer that question with confidence has a solid foundation for cyber resilience. Whether that answer comes from an extensive z/OS security architecture or a carefully secured VSEⁿ environment is, at least initially, secondary.
However, this is where the differences become visible: Which capabilities do the respective operating systems and their product ecosystems provide, and how much additional work remains the responsibility of the organization operating them?
For me, that is the fair basis on which z/OS and VSEⁿ should be compared.
Sources and Further Reading
IBM: z/OS Security Server RACF
https://www.ibm.com/docs/en/zos/3.2.0?topic=zos-security-server-racf
IBM: IBM zSecure Detection
https://www.ibm.com/products/zsecure-detection
IBM: IBM Z Cyber Vault
https://www.ibm.com/products/z-cyber-vault
IBM Redbooks: Security on IBM z/VSE
https://www.redbooks.ibm.com/abstracts/sg247691.html
21CS: VSEⁿ Product Overview
https://21cs.com/products/vsen
21CS: 21CS Announces VSEⁿ 6.4
https://21cs.com/en/resources/articles/21cs-announces-vsen-6-4
21CS: VSEⁿ: A Bold Investment in the Future
https://21cs.com/en/resources/articles/vsen-a-bold-investment-in-the-future
Broadcom: Top Secret for VSE on VSEⁿ 6.x
https://knowledge.broadcom.com/external/article/448059
NIST: Cybersecurity Framework 2.0
https://www.nist.gov/cyberframework
European Union: Regulation (EU) 2022/2554 (DORA)
https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
OpenSSL Project: OpenSSL 3.0 End of Life
https://openssl-library.org/post/2026-09-16-eol30/
Compare how z/OS and VSEⁿ handle access control, threat detection, and cyber recovery – and what those differences mean for your workloads.
A fair comparison of z/OS vs. VSEⁿ security starts with business requirements, operational risks, and recovery needs.
Anyone looking into cybersecurity on IBM Z today will almost inevitably talk about z/OS. The operating system has a comprehensive security architecture, a broad range of specialized tools, and increasingly sophisticated capabilities for detecting suspicious activity and supporting recovery after cyberattacks. IBM has invested heavily in these areas over the past several years.
VSEⁿ, the successor to IBM z/VSE, now developed and maintained by 21st Century Software (21CS), receives considerably less attention. Yet companies running VSEⁿ also operate mission-critical applications, process sensitive information, and must meet requirements for data protection, access security, and recoverability.
Comparing the two operating systems therefore seems reasonable. The problem is that such comparisons can easily lead to the assumption that a larger portfolio of security products automatically translates into a more secure system.
I think that conclusion is too simplistic. The two operating systems have different architectural and operational philosophies, serve somewhat different audiences, and are often deployed under very different economic conditions. As a result, you can’t compare many of their security capabilities on a like-for-like basis.
At the same time, both platforms face certain fundamental security challenges. One of the most important is how an organization protects itself against a successful cyberattack and, more importantly, how it restores a trustworthy operational state afterward.
Two Operating Systems Designed for Different Purposes
z/OS is designed to handle large, complex, and often highly integrated enterprise workloads. Typical environments include extensive transaction processing systems, large database installations, and deeply interconnected batch and online applications. In many organizations, z/OS plays a central role in the overall IT architecture.
That naturally creates significant requirements for centralized administration, detailed logging, automated security controls, and integration with enterprise-wide security operations.
VSEⁿ has a different focus. The operating system primarily serves organizations that want to preserve and continue developing their existing VSE applications and the investments they have made in them. These are often mature, stable batch and OLTP environments that have evolved over decades, with well-understood business functions and technical dependencies.
However, it would be a mistake to associate VSEⁿ exclusively with small companies or less important workloads. Even large enterprises may depend on VSE applications for essential business processes. The size of an organization and the business importance of an application tell us very little about the operating system it runs on.
With VSEⁿ 6.4, released in October 2025, 21CS continued developing the platform, including improvements to cryptographic services, REST support for batch applications, and integration with modern development environments. The company’s product strategy also includes support for current IBM Z hardware. In July 2026, 21CS explicitly confirmed support for IBM z17 Single Frame and Rack Mount systems with appropriately updated VSEⁿ versions.
VSEⁿ is therefore an actively developed platform. The notion that it is merely an old operating system kept alive as long as possible does not reflect recent developments.
These different product strategies matter when comparing security capabilities. z/OS supports a very broad range of workloads and operational models. VSEⁿ focuses more specifically on maintaining and modernizing existing VSE environments. That leads to different expectations regarding functionality, administration, and integration.
An operating system should therefore be evaluated first against the security requirements of the environment where it is actually used.
Shared Hardware Doesn’t Mean Identical Security
Both operating systems benefit from the security architecture of modern IBM Z systems. This includes hardware-assisted cryptography, logical partition isolation, and various mechanisms designed to protect system integrity.
That shared foundation is a significant advantage. However, that doesn’t mean every security feature of a particular IBM Z generation can be used in exactly the same way by both operating systems.
Encryption provides a good example.
With DFSMS Data Set Encryption, z/OS offers a tightly integrated mechanism for encrypting supported VSAM and sequential data sets. Encryption is handled through the standard access methods, so applications generally do not need to be modified, provided the documented requirements are met. Cryptographic key access is controlled through ICSF and the associated security permissions.
VSEⁿ also provides cryptographic capabilities. These include Crypto Services, Encryption Facility for VSEⁿ, and the ability to use encryption features provided by the underlying storage infrastructure. How these mechanisms work together depends on the products involved, the data formats, and the individual installation.
The two approaches are therefore not functionally equivalent in every respect. A meaningful comparison must establish:
- Which data must be protected
- Whether encryption is required at the dataset or storage level
- How cryptographic keys are managed
For example, full storage encryption may satisfy certain requirements for protecting data at rest. However, it does not replace granular access control for individual files or cryptographic keys.
Conversely, even a highly granular encryption architecture offers limited value if key permissions are poorly controlled or administrative access is inadequately protected.
In practice, the overall security design quality makes the difference.
Access Control: Both Platforms Have a Solid Foundation
It would also be unfair to evaluate z/OS and VSEⁿ access security solely by counting the available products.
On z/OS, SAF and an external security manager such as RACF provide the foundation for access control. They allow highly detailed permissions to be defined for data sets, programs, system resources, and numerous other functions. Additional solutions support multi-factor authentication, privileged access management, and the monitoring of security-relevant changes.
The VSEⁿ security architecture builds on z/VSE’s established mechanisms. These include the Basic Security Manager, which supports user and resource protection and logs security-related events. You can also use external security products. For example, Broadcom continues to document the use of Top Secret for VSE in VSEⁿ environments.
This matters because VSEⁿ’s security capabilities are otherwise easy to underestimate.
Nevertheless, z/OS has a considerably broader ecosystem for integrating identity management, privileged access controls, multi-factor authentication, and automated security checks.
With VSEⁿ, it is important to examine:
- which requirements are handled by the operating system itself
- which are addressed by an external security manager
- which depend on infrastructure components outside the system
Also consider the different levels of environmental complexity. A clearly defined VSEⁿ installation with few communication paths may require less administrative effort than a large z/OS environment with numerous interfaces and different user populations.
However, lower complexity doesn’t guarantee better security. Once you introduce external APIs, web applications, database connections, or automated file transfers, additional attack paths emerge that you must address regardless of the operating system.
The Real Difference Becomes Clear in Threat Detection
To me, the comparison becomes particularly interesting when we move beyond traditional protection mechanisms.
A security system must first prevent unauthorized users from accessing sensitive resources. Things become more difficult when an attacker already has valid permissions, perhaps through compromised credentials.
Consider an application that regularly processes a large VSAM file. The associated batch user has all the permissions required to perform the job. One day, however, the same user ID is used to extract unusually large amounts of data or systematically modify records.
Traditional access controls may allow these operations because the user is technically authorized to perform them. The real problem is that the application’s behavior has changed.
This is exactly where IBM has significantly expanded its z/OS security portfolio in recent years.
Solutions such as IBM zSecure, including its current detection components, can monitor security events, analyze unusual data access patterns, and forward suspicious activity to higher-level security systems. Originally introduced through IBM Threat Detection for z/OS and now further developed as IBM zSecure Threat Intelligence, the approach uses techniques such as machine learning to identify unusual access patterns.
Integration with SIEM platforms lets you analyze mainframe events alongside information collected from other enterprise systems. This is particularly valuable for larger organizations whose Security Operations Centers need visibility across the entire IT environment.
VSEⁿ also supports security logging. Its BSM and ESM architecture provides information for audits and security analysis. The technical foundations are described extensively in the IBM Redbook Security on IBM z/VSE.
However, the publicly available product documentation does not currently establish an equally comprehensive, VSEⁿ-oriented solution portfolio for automatically detecting unusual file access patterns and responding immediately.
That certainly does not mean such capabilities are fundamentally impossible on VSEⁿ. External analytics, additional security products, and custom monitoring solutions can perform similar tasks.
The differences mainly lie in the scope of standardized, readily available solutions and the integration effort required.
CALLOUT QUOTE: “A poorly monitored z/OS installation isn’t automatically better protected than a carefully managed VSEⁿ environment simply because more security products are available.”
This is where z/OS has a clear advantage. That advantage becomes particularly relevant when organizations process very large data volumes, connect numerous applications, and need to detect suspicious activity as early as possible.
However, the advantage only materializes when organizations install the right tools, configure them properly, and integrate them into operational response procedures.
A poorly monitored z/OS installation isn’t automatically better protected than a carefully managed VSEⁿ environment simply because more security products are available.
Cyber Resilience Starts Where Traditional High Availability Ends
In my view, an even more important consideration is the distinction between cybersecurity and cyber resilience.
Mainframes have been regarded as exceptionally reliable platforms for decades. Redundant hardware, mature recovery procedures, and extensive data protection capabilities are key reasons they continue to support mission-critical workloads.
But high platform availability does not guarantee that data will remain intact and trustworthy after a successful cyberattack.
Let’s return to our VSAM file. An attacker modifies individual records over several hours. The application continues running, and the changes initially go unnoticed. Regular backups are also working exactly as intended.
The next morning, the business department discovers that customer data has been systematically manipulated.
From an infrastructure perspective, everything may have worked correctly. Yet the organization now faces a serious problem: Which backup still contains consistent, unmodified data? How can that be verified? And how can the affected information be restored without simultaneously losing legitimate business transactions processed in the meantime?
Traditional disaster recovery procedures are often insufficient in this situation.
Both operating systems share the ability to use appropriate functions provided by IBM storage infrastructure. These include IBM DS8000 Safeguarded Copy, which can create protected point-in-time copies that are not directly accessible from production systems.
21CS explicitly documents support for relevant storage capabilities in VSEⁿ. Version 6.4 also introduced improvements to certain console message handling functions associated with Safeguarded Copy.
For z/OS, IBM additionally provides a comprehensively documented solution architecture through IBM Z Cyber Vault. It combines protected backup copies, isolated recovery environments, validation processes, and automated recovery procedures. Depending on the configuration, the implementation may include GDPS and other specialized products.
That represents a significant difference in the scope of available solutions.
However, the comparison needs to remain fair. IBM Z Cyber Vault is an extensive architecture whose implementation requires investment in software, infrastructure, operations, and specialized expertise. Its capabilities should not simply be compared with the standard functions of an individual VSEⁿ installation.
Cyber recovery concepts can also be implemented for VSEⁿ. The relevant questions concern the storage and backup products being used, how recovery is organized, how data integrity is validated, and how applications are brought back into production.
The effort required to automate and validate these procedures may differ considerably.
CALLOUT, Not quote: A protected backup copy is not necessarily a verified, clean recovery point.
That applies equally to both operating systems. For me, it is one of the most important principles of a modern cyber resilience strategy.
Security Capabilities Need Continuous Maintenance
Another issue often overlooked in security comparisons is the ongoing maintenance of the components involved.
With VSEⁿ 6.4, for example, 21CS moved its OpenSSL-based Crypto Services to the OpenSSL 3.0 family. At the time of release, that was an important modernization step. Since then, however, the OpenSSL 3.0 release family reached the end of its regular support period in September 2026.
This does not automatically imply a security vulnerability in VSEⁿ. What matters is the actual software level installed, including available PTFs, and how the vendor provides security fixes. Extended support arrangements or selectively backported fixes may also form part of an appropriate maintenance strategy.
Questions about current cryptographic libraries, supported encryption algorithms, and the handling of known vulnerabilities naturally apply to z/OS as well.
The continued development and maintenance of an operating system are therefore just as important as its original security architecture. Organizations planning to operate a platform for many years need reliable information about maintenance, security updates, and long-term product support.
For VSEⁿ, it is encouraging that 21CS continues to provide a long-term perspective through current releases and announced enhancements. However, for individual capabilities, such as the announced support for IBM Z Secure Boot, it remains important to distinguish between published development plans and functionality that has demonstrably been delivered.
What Does This Mean for DORA and Regulatory Requirements?
For regulated organizations, the ability to demonstrate cyber resilience is becoming increasingly important.
Since January 2025, the European Union’s Digital Operational Resilience Act (DORA) has established comprehensive requirements for ICT risk management, incident response, and the recoverability of mission-critical systems.
Neither z/OS nor VSEⁿ meets these requirements simply because an organization chooses that operating system. Organizations must demonstrate how they:
- Identify relevant risks
- Control access rights
- Detect security incidents
- Regularly verify the effectiveness of their recovery procedures
On z/OS, established tools support many of these tasks. They include solutions for automated compliance checking, security analytics, and preparing evidence for internal and external audits.
VSEⁿ operators can also meet the relevant requirements. Depending on the installation, they may need to use additional products, organizational controls, or custom-developed procedures.
These differences can show up in cost, the degree of automation, and the availability of specialized tools.
Even so, making a blanket statement about the regulatory suitability of either operating system would be unjustified. Regulatory obligations depend on an individual organization’s risks and critical business processes. Their implementation can only be properly assessed by examining the actual system environment.
Economics Belongs in the Security Discussion
One aspect deserves particular attention: Security must work reliably in day-to-day operations and remain economically sustainable.
z/OS has an extensive ecosystem for security management, threat detection, and cyber recovery. This creates significant technical opportunities, particularly for large and complex enterprise environments.
At the same time, these capabilities may add software licensing costs, operational overhead, and requirements for specialized personnel.
VSEⁿ takes a more focused approach. For organizations with clearly defined applications, manageable interfaces, and established operational practices, this approach may continue to make economic sense.
It would be difficult to justify requiring such an installation to implement exactly the same security infrastructure as a large z/OS environment with numerous interfaces and a 24/7 Security Operations Center.
That does not mean economic considerations should weaken fundamental security requirements. If a VSEⁿ application processes sensitive information and is mission-critical to the organization, its recoverability must be assured just as reliably as that of a comparable application running under z/OS.
The central economic question is therefore which security and resilience requirements must be met, and what it costs to satisfy them in a demonstrable and sustainable way within the respective environment.
In some cases, a relatively straightforward architecture may be sufficient. In others, a more extensive system with highly automated security monitoring may ultimately be the more economical choice.
z/OS vs. VSEⁿ Security: What a Fair Comparison Requires
If I were asked to evaluate both operating systems for cyber resilience, I wouldn’t start by listing every available security product. I would begin by defining specific attack scenarios and examining how each installation could handle them.
- What happens, for example, if the credentials of a privileged user are compromised?
- What options exist for detecting unusual access to mission-critical VSAM data?
- How quickly can the organization determine which information has been modified?
- Which protected backup copies are available, and how is their integrity verified?
It would be equally interesting to determine how long application recovery takes and how much data loss, if any, the organization would have to accept.
Such exercises could provide meaningful measurements of detection time, recovery duration, and acceptable data loss. The costs of the required security products and the effort involved in operating them should also be considered.
This type of evaluation would be far more informative than simply comparing product features.
The NIST Cybersecurity Framework 2.0, with its six functions—Govern, Identify, Protect, Detect, Respond, and Recover—would provide a suitable structure. It lets you assess security objectives consistently without making one operating system’s architecture the benchmark from the outset.
Two Viable Platforms, Different Capabilities
After reviewing the available technical documentation, I see a relatively clear picture, though it requires some nuance.
z/OS has a broader, more tightly integrated ecosystem for cybersecurity and cyber resilience. Particularly in automated threat detection, integration with enterprise-wide security operations, compliance automation, and orchestrated cyber recovery, mature solutions are available.
CALLOUt QUote: z/OS has a broader, more tightly integrated ecosystem for cybersecurity and cyber resilience. VSEⁿ, meanwhile, has an established security architecture and benefits from the IBM Z platform’s core strengths.
For organizations running large, complex, and highly interconnected mainframe environments, these capabilities represent a substantial advantage.
VSEⁿ, meanwhile, has an established security architecture and benefits from the IBM Z platform’s core strengths. With ongoing development by 21CS, support for current hardware, and modernization of cryptographic and communication components, it remains a relevant option for existing VSE workloads.
However, VSEⁿ operators more often need to determine which security monitoring and advanced cyber recovery capabilities must be provided through additional products or custom integrations.
These differences do not establish a universally valid ranking of actual system security.
The target audiences, technical requirements, and operational models differ too much for that. Furthermore, the security of any individual installation depends heavily on how consistently existing protection mechanisms are used, access rights are maintained, security events are monitored, and recovery procedures are tested.
The Fundamental Security Question
What I take away from this comparison is a fundamental question that every organization should be able to answer, regardless of its operating system:
After a successful cyberattack, can we demonstrate which data we can still trust, and can we restore our mission-critical applications within the required timeframe?
An organization that can answer that question with confidence has a solid foundation for cyber resilience. Whether that answer comes from an extensive z/OS security architecture or a carefully secured VSEⁿ environment is, at least initially, secondary.
However, this is where the differences become visible: Which capabilities do the respective operating systems and their product ecosystems provide, and how much additional work remains the responsibility of the organization operating them?
For me, that is the fair basis on which z/OS and VSEⁿ should be compared.
Sources and Further Reading
IBM: z/OS Security Server RACF
https://www.ibm.com/docs/en/zos/3.2.0?topic=zos-security-server-racf
IBM: IBM zSecure Detection
https://www.ibm.com/products/zsecure-detection
IBM: IBM Z Cyber Vault
https://www.ibm.com/products/z-cyber-vault
IBM Redbooks: Security on IBM z/VSE
https://www.redbooks.ibm.com/abstracts/sg247691.html
21CS: VSEⁿ Product Overview
https://21cs.com/products/vsen
21CS: 21CS Announces VSEⁿ 6.4
https://21cs.com/en/resources/articles/21cs-announces-vsen-6-4
21CS: VSEⁿ: A Bold Investment in the Future
https://21cs.com/en/resources/articles/vsen-a-bold-investment-in-the-future
Broadcom: Top Secret for VSE on VSEⁿ 6.x
https://knowledge.broadcom.com/external/article/448059
NIST: Cybersecurity Framework 2.0
https://www.nist.gov/cyberframework
European Union: Regulation (EU) 2022/2554 (DORA)
https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
OpenSSL Project: OpenSSL 3.0 End of Life
https://openssl-library.org/post/2026-09-16-eol30/
Don't miss these other great articles
0 Comments