Choose the Control by Data Location
Start with a data-location map. A protected database column can still be copied into a readable save file, exported into the IFS, or sent through an unencrypted service. Mark each location as protected, open, or unknown before choosing software.
Fast encryption coverage decision
| Data location | Native starting point | The proof that matters | When software earns its place |
|---|
| Sensitive DB2 fields | FIELDPROC or SQL encryption functions | An unauthorized storage read cannot reveal the protected value | Central key custody, transparent application use, rotation, and reporting |
| IFS files and extracts | IFS authority plus encrypted storage or application encryption | A copied file remains unreadable without controlled keys | Policy across directories, discovery, reporting, and simpler key use |
| Backups and save media | BRMS software encryption or supported tape hardware | A restore succeeds after keys are recovered from the documented location | Key escrow, policy, media coverage, and recovery reporting |
| Network traffic | DCM certificates and TLS-capable services | A plain client connection is refused | Certificate operations, service coverage, monitoring, and exception control |
Encryption at Rest: Field-Level vs Full-Database
Field-level encryption protects specific sensitive columns, card numbers, national identifiers, account numbers, and leaves the rest of the row readable. It is the more common choice because it limits the performance cost to the data that needs it, and because it maps cleanly onto PCI DSS and similar frameworks that scope compliance around specific sensitive fields rather than whole databases. Full-database or disk-level encryption protects everything uniformly and is far simpler to reason about and prove, at the cost of more overhead and no granularity to narrow an audit scope with.
The honest summary is that field-level is the better answer when you know exactly which columns matter, and full-database is the better answer when you do not, or when nobody can promise you that the list is complete. Plenty of shops end up running both.
Field-Level vs Full-Database Encryption
| Field-Level | Full-Database / Disk-Level |
|---|
| Performance impact | Lower, scoped to specific columns | Higher, applies uniformly |
| Application changes required | Sometimes, depending on product | Typically none |
| Compliance scoping fit (PCI DSS and similar) | Strong, maps to specific sensitive data | Broader, less granular |
| Key management complexity | Per-field or per-table keys | System-wide key management |
| Protects a full-volume or tape theft | Only the encrypted columns | Yes, the whole volume |
| Useful when you cannot enumerate sensitive fields | No, it depends on knowing them | Yes, that is its main advantage |
What IBM i Already Gives You Natively
A fair amount, and this surprises people who assume encryption on IBM i is entirely a third-party purchase. The native pieces are real and they are what most commercial products are built on top of. What you are usually buying from a vendor is key management, policy, reporting, and the part where you do not have to write it yourself.
DB2 FIELDPROCField procedures, available since IBM i 7.1, encrypt and decrypt a column transparently to the application reading it. This is the hook most third-party field-level encryption products actually use.
SQL encryption functionsDB2 for i ships ENCRYPT_AES and matching decrypt functions you can call directly in SQL. Genuinely useful for targeted work, and a lot of manual key handling if you build a whole program on them.
Encrypted independent ASPIBM i can encrypt an independent auxiliary storage pool at the disk level, enabled through a chargeable operating system option. Broad coverage, no application changes, no column-level granularity.
Digital Certificate ManagerDCM holds the certificates every TLS-capable service on the box uses. When transit encryption is not working, DCM is usually where the answer is.
BRMS and tape hardwareBRMS can encrypt save data in software, and LTO-4 and later drives can encrypt in hardware. Two different answers, with two very different key stories.
Key Management Is the Part That Gets Skipped
Encryption is only ever as strong as the key management behind it, and this is where real implementations fall down. Storing encryption keys on the same system as the encrypted data undermines the entire point, because anyone positioned to reach the data is generally positioned to reach the keys sitting next to it. That arrangement will pass a checkbox audit and protect you from almost nothing.
What you want is hardware security module integration, or at minimum keys held and access-controlled separately from the database they protect, with a documented rotation procedure that somebody has actually rehearsed. Ask the harder question too: who can decrypt, and is that list shorter than the list of people who can read the table? If the answers are the same, encryption has not changed your exposure, it has only changed your paperwork.
Backup and Save File Encryption
This is the gap worth checking first, because it is both the most commonly missed and the easiest to reason about. SAVLIB, SAVOBJ, and save files do not encrypt anything on their own. A save file sitting in a library or in the IFS is readable by anyone with authority to it, and a tape carried offsite is readable by whoever is holding the tape.
You have two routes and they are not equivalent. BRMS software encryption protects the save data itself, travels with the media, and costs CPU while the save runs. Hardware encryption on LTO-4 and later drives is effectively free in performance terms but protects only that physical medium, and the keys become a tape-library problem rather than an IBM i one. Encrypted database columns stay encrypted inside a save, which is worth knowing, but that only covers the columns you encrypted and not the rest of the library.
Encryption in Transit
5250 sessions, FTP, and most other network access to IBM i will run in the clear unless TLS was explicitly configured. SSH is encrypted by design, which is one real reason it has steadily replaced Telnet for administrative work. The important word throughout the table below is enforced: on a lot of systems TLS is available, configured, and still quietly falling back to an unencrypted connection when a client asks it to.
Network Access Routes and Their Encryption Story
Test this from a client, not from the configuration screen. The configuration tells you what is permitted. A connection attempt tells you what is actually happening.
| Access route | Encrypted by default | What to verify |
|---|
| 5250 / Telnet | No | Enable TLS on the Telnet server through DCM, then confirm an unencrypted session is refused rather than merely discouraged. |
| FTP | No | Configure FTPS, then check whether plain FTP still answers afterwards. It usually does. |
| ODBC / JDBC host servers | No | TLS is supported and has to be switched on per server, then enforced. This is the route most spreadsheet extracts use. |
| DDM / DRDA | No | Forgotten because it is machine to machine and nobody is watching it fail. Same TLS story, same verification. |
| SSH / SFTP | Yes | Encrypted by design. Still review key handling and which algorithms you are allowing. |
| Web and admin interfaces | Depends | Admin consoles and integrated web server applications should be HTTPS only, with the plain HTTP route closed rather than redirected. |
What Encryption Does Not Do
This is the part that gets oversold, so it is worth being blunt about. Encryption protects data from somebody who reached the storage or the network without going through your authority model. It does nothing whatsoever about somebody who goes through it legitimately. A profile with *USE authority to an encrypted field reads that field in plaintext, because the whole design intent of transparent encryption is that authorised reads keep working.
So encryption is not a substitute for authority management, and it is not a substitute for controlling the network routes into the box. It sits underneath both of those and catches what they miss. A shop with encrypted columns, *PUBLIC *CHANGE on the library, and open ODBC access has not protected that data, it has encrypted it against a threat that was never the most likely one.
How to Judge IBM i Encryption Software
Most IBM i encryption products do the cryptography competently, which means the cryptography is rarely what should decide the purchase. These four questions separate them faster than a feature matrix will.
FIELDPROC or your source code?
A product using field procedures can usually encrypt a column without application changes. One that needs your programs modified turns an infrastructure project into a development project, with a very different timeline.
Where exactly do the keys live?
Ask for the architecture, not the assurance. Separate key store, HSM support, who can decrypt, and what the rotation procedure looks like in practice. This is the question that most changes your real risk.
Does it cover saves and the IFS?
Database columns are the easy part. Ask what happens to that data in a save file, on tape, and sitting in an IFS directory, because those are where copies of it end up.
What does it cost you at peak?
Encryption overhead lands on your busiest batch window, not on the quiet afternoon you tested it in. Insist on measuring against a realistic workload before committing.
Exact option numbers, supported releases, and PTF levels move between IBM i releases, so confirm the specifics for your own release against IBM's current documentation before planning the work. And if you only have appetite for one change this quarter, check your backups first: it is the gap most likely to be open, and the one where the data is already leaving the building.