PK Encrypt · 30-day trial
Your file transfer is encrypted. Your file isn't.
The tunnel closes and the protection ends. That file lands on a distributed server, a partner's system, or a cloud bucket in the clear, and every control you spent the year building sits on the wrong side of the handoff. PK Encrypt puts the protection inside the file itself, in the batch job that already creates it. Try it free for 30 days on z/OS or IBM i.
Protecting regulated data
Largest U.S. commercial banks
Full-feature trial
Protecting 21 of the 25 largest U.S. commercial banks and 30% of the Fortune 100.
The gap
Encrypting the transfer protects the transfer. It doesn't protect the data.
Most mainframe shops are in good shape right up until the handoff. Data sits on the platform behind the access controls you already run, and it's genuinely well protected there. Then a batch job writes a file and something moves it. The tunnel is encrypted. The file inside it isn't.
It lands readable, gets archived readable, and gets copied into test environments, vendor systems, and cloud buckets by people who weren't in the original design review. That's your third-party exposure and your insider exposure, in one sentence.
Same transfer, same schedule, same operators. The only thing that changes is whether the file is readable when it lands.
Where the gap usually hides
Compressed isn't encrypted.
The password protection in the PKZIP base is legacy 96-bit. It stops a curious colleague. It won't stop an attacker and it won't survive an audit. If that's what's protecting files leaving your platform today, the gap is measurable and so is the fix.
What the gap costs
Average cost of a U.S. data breach, per the IBM Cost of a Data Breach Report, 2025. The number nobody tracks is how much of that exposure was protected on the platform and readable everywhere it went next.
What it does
Protection that runs inside the job that creates the data.
No new infrastructure, no agent per environment, no application rewrite. PK Encrypt runs inside the job definition itself, the JCL on z/OS and CL commands on IBM i, so the job that already moves your data now protects it on the way out.
Encrypt the file.
AES-256 at the file level, with X.509 certificate-based and OpenPGP options for partners who don't run PKWARE. Digital signatures on both. The archive is a standard .ZIP, so it opens anywhere ZIP opens, for anyone holding the key.
Protected data your teams can still use.
Most data protection makes data harder to work with. Format-preserving encryption protects the field instead of the whole file, so a 16-digit card number stays 16 digits. Applications reading it downstream don't change. It's deterministic, so protected values still match and join, which is what gets production-shaped data into test environments and vendor feeds without the real values going along.
Prove it happened.
SMF records, the mainframe's own audit trail, tell you what was protected, when, and by which job. That's the artifact an auditor asks for, and the difference between having a control and claiming one.
Run it where the work already runs.
JCL, CLI, and ISPF panels on z/OS. CL commands and panels on IBM i. Command line on Windows, Linux, and Unix. One archive format crosses all of them, so the recipient decrypts with their own key on whatever platform they run.
The upgrade path
If you're already running PKZIP, this is a keyword change.
PK Encrypt is PKZIP with strong cryptography in it. Same engine, same .ZIP archive, same JCL on z/OS, same CL commands on IBM i. If the software is already on your system, you're changing keyword flags on jobs that run tonight. No re-engineering, no operator retraining, and no release window from your application teams.
Installing fresh? It's a standard product install for your platform, and the guide in the package walks every step.
//PKZIPJOB JOB ... //COMPRESS EXEC PGM=PKZIP //SYSPRINT DD SYSOUT=* //SYSIN DD * -ARCHIVE(PROD.PARTNER.FEED.ZIP) -ARCHUNIT(SYSDA)· no encryption keywords ·PROD.CUST.EXTRACT /*
//PKZIPJOB JOB ... //COMPRESS EXEC PGM=PKZIP //SYSPRINT DD SYSOUT=* //SYSIN DD * -ARCHIVE(PROD.PARTNER.FEED.ZIP) -ARCHUNIT(SYSDA) < encryption keywords here > PROD.CUST.EXTRACT /*
Name the jobs.
Which batch jobs write files that leave the platform. Most shops can name the top ten from memory. If nobody owns the full list, that's a discovery problem before it's an encryption problem, and it's what PK Protect is for.
Add the keywords.
Same JCL, same schedule, same operators.
Turn on the logging.
Hand your auditor a report instead of an explanation.
Prove it on one job
One job, two runs, one comparison.
Run a job as it stands and look at what lands at the destination. Add the keywords and run it again. One file is unreadable without the key, and one SMF record shows exactly what happened.
That comparison is the whole product argument, and on a system already running PK Encrypt it takes an afternoon.
After you download
Try it on your own jobs before you commit to anything.
Thirty days with the full product.
Nothing feature-limited, nothing to buy first, and no proof-of-concept project to staff.
Submit the form.
Your download starts on its own.
Watch your inbox.
Your key, the instructions to apply it, and the install guide arrive within one business day. Your 30 days start when that email lands, not when you download, so installation never costs you trial time.
Install and run.
About two hours from a cold start. Closer to thirty minutes if PKZIP or PK Encrypt is already on the system.
Platform depth
Built into the platform, not bolted onto it.
A security tool that burns general-purpose MIPS gets removed at the next license review. PK Encrypt dispatches to hardware first and to the platform's own security services, so cryptography runs on engines you already paid for and your licensing bill doesn't move.
Dispatch order: hardware first, the platform's own crypto software second, PKWARE software last.
On z/OS
ICSF callable services with CPACF on-chip acceleration and CryptoExpress for scale, with explicit control over whether a given operation runs in hardware or in software. Key and access authority runs through SAF, so RACF, ACF2, or Top Secret stays the system of record. zEDC compression and zIIP offload keep the work off general-purpose CPs. Full z17 support.
On IBM i
Qc3 native cryptographic services, dispatching to Power crypto hardware before falling back to software, with certificate stores governed through Object Authority. iPSRA pipes SAVLIB and SAVOBJ straight into a protected archive, and the Spool File Handler converts spool output and protects it in one step.
Full capability matrix by platform and release is in the documentation set that ships with the trial. The solution brief goes deeper on the architecture, and there's no form on it. If you'd rather argue about dispatch order with someone who knows the answer, that's a call we're glad to have.
Keys and recovery
Encryption you can recover from.
The objection is never “can you encrypt it.” It's what happens if you can't get it back. Keys live in the platform's own key stores, with authority running through the security manager you already run instead of a separate console nobody reviews.
Protected key support means the clear key value never leaves the hardware. Keys rotate in place with a cache flush and no application downtime, so rotation isn't an outage you schedule around.
The quantum clock
Keep your AES. Replace your RSA.
Post-quantum migration gets sold as a rebuild, which is why most programs haven't started. The arithmetic is narrower than that. AES-256 holds. Grover's algorithm halves the effective work to 2128, and exhausting that key space is beyond anything anyone can build.
RSA is the problem. It falls to factoring rather than brute force, and NIST already rates RSA-2048 at 112-bit security and sunsets it after 2030. So the job isn't replacing your encryption. It's replacing the public-key layer that wraps your keys and signs your files, before the data you shipped years ago gets read.
Harvest now, decrypt later doesn't need a quantum computer. It needs a hard drive and patience. The files most at risk are the ones you encrypted years ago and stopped thinking about, on retention schedules that outlive the algorithm protecting them.
This isn't PKWARE's first one. In 2000, PKWARE's predecessor was denied a mass-market export license because its encryption was too strong to qualify. Every transition since, DES to AES and software cryptography to IBM crypto hardware, shipped without breaking a customer's batch job.
Which product you need
One question tells you where to start.
PK Protect and PK Encrypt are two products under one roof. They share a protection engine and they solve different opening problems, so pick by the sentence you'd use to describe your week.
“I don't know where all my sensitive data is.”
Start with PK Protect. Discovery and classification first, protection second, across endpoint, cloud, and mainframe under one policy.
“I know exactly where it is. I need it protected in the jobs that move it tonight.”
That's PK Encrypt. Start the trial.
“Both, and we're on z/OS or IBM i.”
PK Protect, with PK Encrypt as the cryptographic engine underneath it.
SecureZIP customers: you're already on this product. SecureZIP is PK Encrypt.
Straight answers
Mainframe encryption software, answered.
Mainframe encryption software protects data on and leaving IBM Z and IBM i systems by encrypting the data itself rather than the channel it travels through. It runs inside existing batch jobs, uses the platform's own cryptographic hardware and security services, and produces an audit record of what was protected. The protection stays with the file after it reaches a distributed system, a partner, or cloud storage.
No. Transfer encryption such as SFTP, FTPS, or managed file transfer protects data while it's moving and stops at the destination. The file is written to disk in the clear on the receiving system unless the file itself is encrypted. File-level encryption travels with the data through every copy, archive, and downstream system.
The full product, version 17, with a 30-day license. The package includes the install job, the interface for your platform, and the complete documentation set: Users, Messages, System Administrators, Application Integration, and Security Administrators guides in one searchable PDF. Nothing in the trial is feature-limited.
You don't have to do anything. Submitting the form starts it, and your key arrives by email within one business day along with the instructions to apply it and the install guide. There's no license report to run and no machine details to look up. Your 30 days start when that email lands rather than when you download, so installation never costs you trial time.
Yes. Your key comes through your regional dealer rather than directly from us, and we route you when you submit. Nothing changes about the 30 days or what's in the package.
About two hours from a cold start on z/OS, and closer to thirty minutes if PKZIP or PK Encrypt is already on the system, since the software is already there and you're changing keywords. IBM i is simpler than z/OS. The install guide and the full documentation set ship in the package.
The trial covers z/OS and IBM i, and you pick yours on the form. Both get the same 30-day term and the same licensing process. PK Encrypt also runs on Windows, Linux, and Unix, which is what lets a partner open a protected archive on their own platform without running the trial themselves.
PK Encrypt is PKZIP with strong cryptography added. They share the same engine, the same .ZIP archive format, and the same JCL. The password protection in the PKZIP base is legacy 96-bit encryption and it isn't strong cryptography in the modern sense. Upgrading is a keyword change on existing jobs, not an application rewrite.
Yes. On z/OS, PK Encrypt calls ICSF services and uses CPACF on-chip acceleration for hashing and CryptoExpress coprocessors for scale, with zEDC for compression and zIIP offload to keep work off general-purpose processors. On IBM i, it dispatches to Power crypto hardware through Qc3 before falling back to software.
Yes, at 256-bit key length. Quantum computers attack symmetric encryption through Grover's algorithm, which halves the effective work to 2^128 and leaves AES-256 with 128-bit strength. The urgent exposure is in public-key cryptography such as RSA and elliptic curve, which fall to Shor's algorithm. NIST rates RSA-2048 at 112-bit security and sunsets it after 2030.
Existing archives stay readable. PKWARE's approach to every cryptographic transition it has shipped through has been continuity, which means existing decrypt jobs keep working while new protection arrives underneath. That matters more on a mainframe than anywhere else, because the retention schedule on the data usually outlasts the algorithm that protected it.
They're two products under one roof, not a product and a module. PK Protect leads with discovery and classification across endpoint, cloud, and mainframe. PK Encrypt leads with protection inside batch and file jobs. They share a protection engine, and on the mainframe PK Encrypt is the cryptographic engine underneath PK Protect. If you know where your sensitive data is and need it protected in the jobs that move it, start with PK Encrypt.
Start here
The file leaves tonight either way.
Encrypted or not is a configuration decision. Take 30 days and find out which of your jobs are shipping data in the clear.
Protecting regulated data on z/OS and IBM i for four decades