Mainframe Penetration Testing
Mainframe penetration testing across Europe: z/OS, RACF, CICS and Db2 assessed by specialist offensive engineers. Fixed price, free retest, attestation.
Mainframe penetration testing brings offensive security to the systems most testers never touch: z/OS running RACF, ACF2 or Top Secret, with CICS, IMS and Db2 behind it, holding the core banking, insurance and government records an organisation cannot afford to lose. We test the platform as a real attacker would, because “nobody understands the mainframe” is a security assumption, not a security control.
The mainframe is often the most critical and least tested system in the estate. It is decades old, deeply trusted, connected to everything, and protected by a belief that its obscurity keeps it safe. That belief does not survive contact with someone who knows z/OS. A misconfigured RACF profile, an APF-authorised library anyone can write to, or a single magic SVC can take an ordinary user to full system control, and from there to every record on the box.
What mainframe penetration testing covers
We assess the platform from the position an attacker realistically reaches: a low-privilege user account, or a foothold via a network-exposed service. From there we go after the external security manager, the authorised code that runs above it, and the applications and data that make the mainframe worth attacking.
How we run a mainframe penetration test
The work is done by engineers who know the platform, not web testers guessing at green screens. We follow the same logic as any assessment, adapted to z/OS: understand the security model, find the low-privilege foothold, and escalate methodically toward the authority that owns the system.
Reconnaissance and access
We start from what an attacker would have: network access to the mainframe’s exposed services, or a standard TSO user account. We enumerate the listening services, the security software in use, and the accounts and resources visible from that starting point. Even from a plain user ID, z/OS reveals a great deal about how it is configured.
Reviewing the security manager
The external security manager, RACF, ACF2 or Top Secret, is the heart of z/OS security, and its configuration is where most serious findings live. We analyse the profiles, the user attributes, and the access rules, looking for the accounts with excessive authority, the resources protected too loosely, and the settings that quietly weaken the whole system.
The paths to SPECIAL and OPERATIONS
The prize is system-level authority: the SPECIAL attribute that controls security, OPERATIONS that reaches almost any dataset, and equivalents in ACF2 and Top Secret. We test the routes ordinary users can take to get there, because a single over-permissioned profile or an inheritable attribute is often all it takes.
Authorised code and escalation
Above the security manager sits authorised code that can bypass it. We look for APF-authorised libraries that non-privileged users can update, user SVCs that grant authority without proper checks (the classic magic SVC), and program-control weaknesses. These are the escalation paths that turn a normal user into an unstoppable one, and they are common on systems that have accumulated decades of software.
Application and data layer
We test the subsystems that run the business: CICS transactions and their security, IMS, and Db2 authorisation. A transaction that runs with more authority than the user calling it, or a database grant that is too broad, can expose or alter the exact records the mainframe exists to protect.
Reporting
You get a report written for both mainframe systems programmers and the risk owners who rarely see inside the platform, with each finding tied to the specific profile, library or setting at fault.
Weaknesses we commonly find
Mainframes fail security in ways that are specific to the platform and remarkably consistent across sites, usually the residue of decades of change with light review.
Over-privileged accounts
Far too many user IDs holding SPECIAL, OPERATIONS or their ACF2 and Top Secret equivalents, often granted years ago for a task long finished. Every one is a full compromise waiting for a stolen password.
Writable APF-authorised libraries
Authorised libraries that ordinary users can update. Anyone who can write to one can run code with system authority and bypass the security manager entirely. It is one of the highest-impact findings on the platform and it turns up more often than it should.
Loose dataset protection
Datasets holding sensitive data, or the security database itself, protected by profiles with universal read or update access. Sometimes there is no protecting profile at all, and default access decides who gets in.
Weak network-facing services
TN3270 without encryption, FTP that exposes datasets and JES, and z/OSMF or REST connectors bolted on to modernise the platform without the same rigour as the core. Modern connectivity is often where the old system’s new weaknesses enter.
Default and stale credentials
Vendor default accounts left active, shared IDs with unchanged passwords, and dormant privileged accounts nobody removed. On a system this trusted, one live default credential can be the whole attack.
Tools and technique
Mainframe testing relies far more on expertise than on tooling, but we use what exists: RACF database unload with IRRDBU00 and analysis of the results for privilege and access issues, TN3270 clients for interactive testing, service enumeration with nmap and platform-aware scripts, and mainframe-specific offensive tooling for privilege-escalation checks. Every finding is confirmed by hand on the actual system. There is no scanner that “does mainframes”; the value is an engineer who understands z/OS internals reading the configuration for what it really allows.
Want this tested on your own systems?
Free 20-minute scoping call, a fixed price with no hourly surprises, and a free retest once you fix what we find.
What you get
The deliverables translate deep platform findings into action for teams on both sides of the mainframe.
- An executive summary that explains the risk to leadership without assuming they know z/OS.
- A technical report with each finding scored, the exact profile, library, service or setting identified, reproduction detail, and a fix your systems programmers can apply.
- Findings prioritised so escalation-to-SPECIAL paths come before minor hygiene items.
- A remediation call with the reviewing engineer and a free retest once you have fixed.
- An attestation letter mapped to the framework you report against.
Compliance and standards
Mainframes usually sit at the centre of regulated processing, so testing them supports the frameworks that matter most in finance and government. PCI DSS requirement 11.4 applies where the mainframe is in the cardholder data environment, and our report is written to that. ISO 27001:2022 access-control clauses A.5.15 through A.5.18 map directly to RACF and its peers, DORA obliges financial entities to test their critical ICT, and GDPR expects appropriate protection of the personal data these systems hold. We align the report and attestation to whichever you answer to.
From an ordinary user ID to owning the system
The escalation path on a mainframe is specific to the platform, and walking it shows why obscurity is no defence. We start with a plain TSO user, the kind of account a phished employee or a compromised connected system might hand an attacker. Even from there, z/OS discloses a great deal about how it is configured and what is protected loosely.
Finding the weak link
From that account we look for the one misstep that grants authority: an APF-authorised library we can write to, a user SVC that hands out privilege without checking the caller, a dataset profile with universal update, or an account whose attributes we can inherit. Any single one of these can be enough, and mature systems that have accumulated software for decades tend to have several.
What system authority means
Reaching SPECIAL or OPERATIONS, or their ACF2 and Top Secret equivalents, means control of the security policy itself and access to nearly every dataset on the box. On a system running core banking or government records, that is effectively total compromise, which is why we test these paths specifically rather than treating the mainframe as a black box.
Testing a system you cannot simply reboot
A production mainframe runs workloads an organisation cannot interrupt, and we test accordingly. Wherever possible we work on a test LPAR or within an agreed maintenance window for anything intrusive, keep our actions reversible, and confirm the rules of engagement before touching a privileged path. The goal is a genuine assessment of what an attacker could do, achieved without putting the transactions the business depends on at risk.
Pricing
The mainframe penetration testing cost depends on the size of the environment, the security software in use, how many LPARs and subsystems are in scope, and whether the assessment is authenticated from a user ID or starts from the network. Specialist work is scoped honestly rather than sold by the hour.
| Engagement | What’s included | Timeline | Price |
|---|---|---|---|
| Focused review | Single LPAR, one security manager, authenticated privilege-escalation testing, key dataset and APF review, report and free retest | 5–8 working days | from €5,000 |
| Standard | Multiple LPARs or subsystems, CICS and Db2 security, network-exposed services, USS, exec + technical report | 8–12 working days | €8,000–€18,000 |
| Advanced | Complex environment, full escalation testing to system authority, network entry point, application deep-dive, attack-chaining | 12–20 working days | €18,000–€40,000 |
| Compliance add-on | Mapping and attestation letter for PCI DSS, ISO 27001, DORA or SOC 2 | with any tier | from €1,000 |
| Custom / large estate | Multiple sysplexes and business-critical subsystems, scoped to your needs | on scoping | custom |
Every engagement is fixed-price, quoted after a free 20-minute scoping call — no hourly surprises, and a retest is included. Get a fixed quote
FAQ
How much does mainframe penetration testing cost?
Do you actually have mainframe expertise, or is this a network test?
Will the test affect our production workload?
Do you test from an existing user ID or from the network?
Which security managers do you cover?
Do you look at CICS, Db2 and modern connectors too?
Will this satisfy PCI DSS, DORA or ISO 27001?
Is a retest included after we fix?
Related services
Banks, insurers, government bodies and large enterprises running core workloads on IBM Z and z/OS, teams whose auditors or regulators expect the mainframe to be tested like any other critical system, and organisations modernising mainframe access who need the new connectivity checked. We are a European offensive-security team working with clients EU-wide and remotely.
Security you can prove
The same standard on every engagement, big or small.
Evidence, not opinions
Every finding ships with a reproduction and proof of concept — no vague "maybe vulnerable".
Humans over scanners
Certified engineers find the logic flaws and chained attacks automated tools walk straight past.
Fixed price, free retest
You know the cost up front, and verifying the fix is part of the deal — not a second invoice.
Ready to lock this down?
Free scoping call, fixed price, free retest. Tell us what you're running and we'll take it from there — usually within one business day.
Tell us what you're running
Scoping is free. We reply within one business day, and under 30 minutes for active incidents.