PK Protect Endpoint Manager + Mail Transfer Agent
Your DLP inspects everything you send. Except what's encrypted.
Encrypted file inspection, running inside the DLP you already own. PK Protect Endpoint Manager and the Mail Transfer Agent make encrypted files readable to your existing policies, inline, using a key only you hold. Nothing changes for the sender, the recipient, or your policy set.
Protecting 21 of the 25 largest U.S. commercial banks and 30% of the Fortune 100.
What your DLP misses
Encryption is where your DLP stops.
Your data loss prevention (DLP) system reads what leaves. It can't read an encrypted file. So every encrypted attachment and every encrypted upload is a place where the control doesn't operate.
One gap, four separate findings. Each one below is something an auditor can write up.
An audit answer that stopped working.
Auditors want to know what sensitive data left, encrypted or not. “It was encrypted” isn't a sufficient answer anymore. And you can't claim you inspect encrypted files when you have no way to open them.
Blind enforcement.
When your DLP hits an encrypted file, it can block it or pass it. Blocking breaks a legitimate business process. Passing sends data out uninspected. There's no third option today.
An open exfiltration path.
Anyone can encrypt sensitive data with a passphrase you never see, send it to a personal cloud account, and open it there with free tooling. Standard DLP misses it entirely.
Files you can't open either.
Passphrase-encrypted files are gone for good when the passphrase is lost or its owner leaves. That's not hypothetical. Companies have failed audits over encrypted files they couldn't produce.
Why workarounds fail
The workarounds don't close this.
Asking the sender for the passphrase makes inspection depend on the person being inspected. It breaks on honest error, and anyone acting deliberately defeats it in a second.
Routing encrypted files to a manager for approval is no better. The manager can't see inside the file either, so the approval only confirms what the sender said it was.
Neither one ever inspects content. They add friction and hand a blind decision to a human.
The choice you have today
Today an encrypted file gets blocked or it gets passed. There is no third option.
The MTA adds the third option. It makes the file readable to your own DLP, inside your own environment. You choose the scope it covers.
How it works
The fix starts with the encryption, not the inspection.
Whether an encrypted file can be opened is decided when the file is encrypted, not by the tool trying to inspect it. If you hold no key to the file, no DLP can read it, no matter how good it is.
That's why the answer starts with the encryption product. If your encryption vendor doesn't give you a key of your own, nothing downstream can open the file. No DLP, no add-on, no integration.
Standardizing encryption on PK Protect Endpoint Manager (PEM) is what makes the channel inspectable. PEM wraps every protected file with the key in use, whether that's a PGP key, a certificate, a PK Protect Smartkey, or a passphrase, plus your own contingency key.
The private half never crosses the line. PKWARE can't open your files.
You generate the key pair.
You give PKWARE the public half and keep the private half in your own key vault, secrets manager, or HSM.
The MTA uses the private half.
That private key is what the MTA uses to decrypt in the workflow. The sender is never asked for anything. PKWARE never holds the key.
The same key is your recovery path.
It's permanent. Any file PK Protect encrypted can be opened, whatever happened to the original passphrase.
The flow
Your DLP stays in charge.
It decides what to route, it does the inspection, and it makes the call. The Mail Transfer Agent (MTA) exists to make the content readable.
- Detect. Your DLP finds an encrypted file it can't inspect and routes it to the MTA instead of blocking it.
- Decrypt. The MTA decrypts with your contingency key and hands the readable content back.
- Inspect. Your DLP checks the content against the policies it already runs and applies whatever those policies call for. Deliver, block, quarantine, alert.
- Clean up. If the file is clean, your DLP routes the message back and the MTA removes every unencrypted copy.
- Deliver. The original encrypted file goes to the recipient, unchanged.
It runs inline in the SMTP mail path, so every encrypted attachment your people send passes through it before the message leaves.
Free encryption tools
Most encryption in your company runs on tools nobody supports.
Most of it was chosen by whoever needed to send a file that afternoon. They downloaded a ZIP tool and typed a passphrase. 7-Zip, WinZip, whatever came up first. It's on an unknown number of machines, doing real work, and nobody owns it.
The encryption itself is usually fine. Everything around it is missing. No support contract, so nobody's obligated to ship a patch when a vulnerability gets disclosed. No central policy, so nothing governs how it's used. No version reporting, so you can't answer which machines are running what. And no key your company holds, which is why your DLP can't inspect those files and your administrators can't recover them.
Auditors have started treating that as a finding on its own, separately from anything to do with inspection. An unowned control isn't a control.
PK Protect is commercially supported and actively maintained. Policy is set once in PEM, and the console reports client presence and version state, so you always know what's deployed and where.
Scope
You choose the scope. Everything inside it is covered.
That's what makes this a business-unit decision instead of a company-wide program. The MTA only opens what PK Protect protected, so any other encryption tool left inside the covered scope produces files it can't decrypt, and your DLP still can't inspect them.
You pick the scope. A business unit, a region, or the whole company. The control is complete over whatever standardizes. What it can't tolerate is another encryption tool sitting inside that scope.
Requirements
The requirements this control has to meet.
Here's what a control of this type has to do, why each one matters, and how PKWARE does it. Take the left column to any vendor and ask.
Group 1 · Can it open the file?
01Decrypt attachments inline, in the mail flow, so the DLP you already run inspects the real file content.
Why it's on the listWithout it, every action your DLP takes on that file is blind, and blind doesn't answer an audit finding.
How PKWARE does itThe MTA takes the message from your DLP over SMTP, decrypts the attachment, and returns readable content for policy inspection.
02Decrypt without ever asking the sender for the passphrase.
Why it's on the listA passphrase you never see is the exfiltration path, and any process that depends on the user disclosing it is defeated by anyone acting deliberately.
How PKWARE does itEvery file PK Protect protects is wrapped with both the key in use and your contingency key. The MTA uses the contingency key. The user is never involved.
03Recover any encrypted file, any time, without the original passphrase.
Why it's on the listCompanies have failed audits because they couldn't open their own files after a passphrase was lost. It's a data availability exposure you're carrying today without seeing it.
How PKWARE does itThe contingency key is a permanent recovery path. Designated administrators can open any protected file, including after the employee is gone.
Group 2 · Does it fit what you already run?
04Work with the DLP you already deployed, using its policies and its actions.
Why it's on the listRebuilding a tuned policy set in a second product is expensive, and it gives policy two places to drift.
How PKWARE does itThe MTA doesn't inspect. It makes unreadable content readable for the DLP already in place. Your existing rules and actions apply unchanged.
05Integrate with your deployed DLP without a custom development project.
Why it's on the listAn integration that needs custom code is an open-ended internal cost and an upgrade risk with no owner.
How PKWARE does itThe MTA is a standard SMTP hop in the mail flow. Any DLP that can route messages routes to it with configuration, not code. PKWARE supports that configuration as part of the deployment.
Group 3 · Will it hold in production?
06Fail safe at every stage of the flow.
Why it's on the listA failure that passes silently sends sensitive data out uninspected, or unencrypted.
How PKWARE does itEvery stage carries an explicit success or failure state. A message moves forward only on confirmed success. A failed decrypt routes to exception handling, and delivery only happens on confirmed cleanup.
07Run with no single point of failure in the mail path.
Why it's on the listThe flow fails safe rather than passing data through, so an outage holds mail and availability becomes a production requirement.
How PKWARE does itThe MTA runs as a pool of instances, deployed and routed to match your environment, within one data center, across separated data centers, or aligned to your existing DR design, with automatic failover.
08Deploy where you choose, on-premises or in cloud, and keep data in region.
Why it's on the listPlacement decides your sovereignty answer, and you should be the one making that call.
How PKWARE does itThe MTA runs in your own data centers or your cloud tenancy in Azure or AWS. It runs on RPM- and Debian-based Linux alike, with Red Hat Enterprise Linux as the reference platform and native packages shipped for both families in every release.
Group 4 · Can you own it and prove it?
09Standardize on supported, maintained encryption software with central policy and version visibility.
Why it's on the listNobody is obligated to patch a user-installed tool, so the next disclosed vulnerability becomes an unknown exposure across an unknown population.
How PKWARE does itPK Protect is commercially supported and actively maintained, with regular releases and vulnerability patches. Policy is set once in PEM, and the console reports client presence and version state, so you always know what's deployed and where.
10Produce evidence that outbound encrypted files were inspected.
Why it's on the listAuditors don't accept encryption as the answer. They want to know what sensitive data left, encrypted or not.
How PKWARE does itInspection happens inside your own DLP, so its existing reporting now covers encrypted traffic. Compliance can state that all outbound encrypted files are inspected.
11Require nothing of the external recipient.
Why it's on the listAnything that makes your counterparty register or install software changes the relationship, and the business pushes back on it.
How PKWARE does itThe recipient opens a standard password-protected file with tooling they already have. No account, no portal, no PKWARE software.
The solution brief walks the same eleven requirements with the architecture underneath them.
Where this fits
One question tells you where to start.
“We already use PKWARE encryption.”
Then start from what's deployed. Bring your current version and policy state to the working session and we'll map what changes and what doesn't.
“My DLP passes encrypted files and I need that path inspected.”
That's PEM plus the MTA. PEM handles the encryption, the MTA handles the decrypt, and your DLP handles everything else.
“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 need the files my batch jobs write protected on the way out.”
That's PK Encrypt, inside the job that already creates the file.
Further reading: why DLP is not enough to support your data security posture.
Straight answers
Encrypted file inspection, answered.
Because DLP inspects content, and encrypted content is unreadable without the key. When a user encrypts a file with a passphrase your organization never sees, no inspection engine can open it, so the DLP is left choosing between blocking the file and passing it uninspected. The capability is decided by who holds the key, not by the quality of the DLP.
You need a key your organization holds on every file that gets encrypted, and a step in the outbound path that uses it. PK Protect Endpoint Manager wraps every file it protects with a contingency key you generate and keep, and the Mail Transfer Agent uses that key to decrypt inline so your DLP can inspect the real content. Visibility comes from the encryption side, not from the inspection side.
No. You generate the contingency key pair, give PKWARE the public half, and keep the private half in your own key vault, secrets manager, or HSM. The MTA runs in your own environment and uses your private key there, so PKWARE has no ability to open your files.
It can be, and increasingly it is. The encryption is usually sound, but a user-installed tool has no support contract, no obligation to ship security patches, no central policy, and no version reporting, so you can't say which machines are running what. It also produces files only the person who chose the passphrase can open, which means no inspection and no recovery.
No. The MTA doesn't inspect and doesn't enforce. Your existing policies, actions, and reporting stay exactly as they are, and they now cover encrypted traffic instead of stopping at it.
No. The recipient receives the original encrypted file, unchanged, and opens it with the tooling they already have. There's no account to create, no portal to log into, and no software to install.
Start here
Nobody can tell you how much encrypted data left last month.
That's not a reporting gap. That's the control gap. Bring your DLP, your outbound path, and the scope you'd standardize, and we'll map where the MTA sits and what the control covers.
Your DLP · Your keys · Your environment · Your policies, unchanged