Reading Vendor Security Claims Without Getting Fooled

Open four transfer vendors' security pages side by side and read them aloud. The phrases repeat: military-grade encryption, bank-level protection, fully compliant, trusted by thousands. By the third page you could recite the fourth. Read enough of them and a strange feeling sets in: if everyone is this secure, how does anyone ever get breached? The answer is that security pages are written to reassure buyers, not to inform administrators. Most were last touched by someone in marketing. The information you need is usually in there somewhere, or provably absent; either way, someone has to translate.

That someone is you. This article is the translation kit. It gives you a decode table for the most common claims. It gives an honest explanation of what attestation reports and certifications do and do not prove. It offers a method for verifying claims yourself in a trial. It covers the quieter signals that distinguish vendors who take security seriously from vendors who take marketing seriously. It is part of our Vendor Assessment series. It comes with the standing disclosure: Sysax sells transfer software and writes product pages too. This is the decoder ring — use it on our pages as readily as anyone else's.

Why Security Marketing Sounds the Way It Does

Most vendor security claims are not lies; they are compressions, and holding on to that calibration will keep you fair. "Military-grade encryption" usually compresses "we use the same standard, publicly vetted encryption algorithms as everyone else, including militaries". That is true, unremarkable, and shared with every competent product on the market. The sentence is written for a buyer who scans; it is designed to end a worry, not to open an inquiry.

Watch the move in action. Imagine a security page that reads: "Your files are protected with military-grade encryption, end to end. Our platform is fully compliant with HIPAA, PCI DSS, and GDPR, independently certified, and trusted by thousands of organizations worldwide. We have never suffered a security breach." There are five claims in three sentences. Here is what each becomes once translated. Standard algorithms are fine — which ones, and can you configure them? Does "end to end" mean in transit only, or at rest too? "Fully compliant" is a category error — compliance belongs to organizations, not products. For "independently certified," what scope is certified, and can you read the report? "Never breached" is unverifiable, and irrelevant next to how they handle vulnerabilities. Nothing in the paragraph was necessarily false. Everything in it needed translation before it could inform a decision.

The sin, when there is one, is implication. A claim can be technically accurate while inviting you to conclude something much stronger. You might conclude that encryption is unbreakable, that a certification covers the product's code, or that a compliance badge transfers compliance to you. None of those conclusions follow, and the vendor never quite said they did. So the working method of this whole article is a single move, applied over and over: translate every claim into a checkable fact, then check it. A claim that survives translation is information. A claim that evaporates under translation was decoration.

The Decode Table

The table below covers the claims you will meet most often on transfer-product security pages. It shows what each one sounds like it means, and the concrete thing to check instead. It is the copyable heart of this article — keep it next to you while you read any vendor's site, ours included.

Two of these rows deserve a longer look, because they carry the most weight in real evaluations: the compliance row and the certification row.

On compliance: regulations bind organizations and their processes, not software boxes. A transfer product can absolutely make your compliance work easier. Encryption, access control, and logging are recurring demands across frameworks, as our compliance frameworks series explains. But the product cannot hold the obligation for you. The precise, useful question is: "which requirements does this help us satisfy, in which configuration?" A vendor who answers that question with a mapping document is being genuinely helpful. A vendor who repeats the word "compliant" is selling.

On "end-to-end": the phrase has a strict meaning — encrypted from origin to final recipient with no decryption in between. It has a loose marketing meaning that often amounts to "we use encrypted connections." The distinction between protecting data in motion and protecting it at rest is fundamental enough that we gave it its own article, at rest vs in transit. If true end-to-end protection matters for your flow, file-level encryption before sending is how it is actually achieved, and a candid vendor will say so. (A less candid one will say "end to end" again, slightly louder.)

One claim missing from the table deserves its own note: "independently penetration tested." A penetration test is a paid engagement where security professionals attack the product or service and report what they find. It is genuinely valuable, which is exactly why the claim needs scoping. Ask when the most recent test happened, what was in scope, whether serious findings were fixed and re-tested, and whether a summary letter is available. A test from many years ago, scoped to a marketing site rather than the product, proves close to nothing. A recent test with an attestation letter and a fix-and-retest cycle is one of the stronger pieces of evidence a vendor can offer. (The marketing site, to be fair, usually passes.)

What Attestations Prove — and What They Don't

Attestations and certifications are the most substantial objects in vendor marketing, so they deserve the most careful reading. You will meet two constantly. One is SOC 2, an independent auditor's report on a service organization's controls (security, availability, confidentiality, and related criteria). It reports whether those controls are suitably designed. In the more valuable variant, it also reports whether they operated effectively over a stated period. The other is ISO 27001, a certification that an organization runs a structured, audited management system for information security.

Here is what an attestation genuinely gives you: an outside party looked at the organization's controls and wrote down what they found. That is real, and it is more than most vendors offered historically. Here is what it does not give you, and honest vendors will confirm every item on this list:

• It does not prove the product's code is secure. Attestations examine organizational controls — hiring, access, change management, operations. A company can pass while its product carries a serious vulnerability; the industry's worst transfer-product breaches happened at attested organizations.
• Scope is everything. The report covers specific systems and services during a specific period. The service you are buying may sit partly or wholly outside it. Read the scope section first; it is short and decisive.
• Exceptions live in the body. Auditor reports note deviations — controls that were not operating as described. A badge on a website does not show the exceptions; the report does. If a vendor will share only the badge and never the report, weigh that.
• It does not configure your deployment. The most attested vendor on earth cannot stop you from exposing an unpatched server with weak passwords. Your half of the security remains your half.

Relevance also varies by delivery model, and this cuts in both directions. For a hosted service, organizational attestations matter enormously. The vendor's operations staff, systems, and controls hold your files daily, and SOC 2 style evidence is a reasonable thing to expect. For self-hosted software, the vendor's operational controls never touch your data. So an organizational attestation tells you less about what you are actually buying. Questions about development practice, advisories, and patching tell you more. That is why a small self-hosted vendor without a certification is not automatically a worse bet than an attested giant. It means the evidence that matters lives somewhere else. The delivery-model trade gets its full, honest treatment in self-hosted vs SaaS risk.

Verify It Yourself: The Trial Is an Assessment Tool

Everything so far has been about reading. The strongest move in claim-checking is not reading at all — it is verification: making the product demonstrate its claims on a machine you control. Any vendor claim about protocols, settings, logging, or lockout behavior is testable in an afternoon with a trial installation. A vendor who offers a genuine free trial is, deliberately or not, inviting exactly this. We publish ours on the download page. We will say plainly, as a vendor: a vendor who wants payment before any claim can be tested is asking for belief. Belief is not an assessment method.

Run the trial in a test network — never straight into production — and work through a checklist like this:

TRIAL VERIFICATION PASS — one afternoon, one test server

[ ] Install on a clean test machine; note what privileges the installer asks for
[ ] Connect with real clients over each claimed protocol; confirm each works
    (and confirm you can DISABLE the ones you do not want)
[ ] Inspect the negotiated encryption with your client's connection details;
    confirm you can restrict weak options in the server's settings
[ ] Upload, download, rename, delete as a test user; then read the logs -
    is every action there, with user, source address, and timestamp?
[ ] Fail sign-ins on purpose; confirm lockout or throttling behaves as claimed
    and that the failures are logged
[ ] Check every security-relevant default: anonymous access off? plain FTP
    off or clearly flagged? administrative interface reachable only where
    you expect?
[ ] Note every mismatch between claim, documentation, and behavior

This is the same muscle you use when verifying your own hardening work. The fuller method — including testing from outside your network — is in verifying a hardened transfer server. If inspecting negotiated encryption is new territory, how TLS protects transfers explains what those connection details mean.

To be concrete about how this applies to us: consider the claims we make for Sysax Multi Server. They cover FTPS, SFTP, and HTTPS alongside legacy FTP, activity logging to file and database, IP allow and block rules, and a FIPS 140-2 mode. All are checkable by exactly this method in the trial. That is how we would want you to treat them. The same goes for any competitor whose page you are reading this week. Claims that survive the afternoon are facts; the rest were formatting.

Keep the worksheet. A record that says "claimed, tested, confirmed" — or "claimed, tested, failed, vendor response attached" — is worth more in your decision file than any brochure. It becomes the baseline for the re-checks described in vendor security after the purchase.

Meridian Parts learned the value of that worksheet during a hosted-service trial. The vendor's page said "encrypted at rest," and the assessor, following the decode table, asked what that meant and who held the keys. The answer, after two follow-ups, was that the storage volumes were encrypted by the cloud provider. That protects against a stolen disk and against nothing that logs in. A support engineer with tenant access could read the files in the clear. The sentence on the page had not been false. It had been written by someone who was never asked the second question. Meridian chose something else, and the worksheet line read "claimed, asked, clarified, declined."

The Quiet Signals of a Serious Vendor

Beyond the loud claims, vendors give off quieter signals that are hard to fake because they cost real engineering effort. When you find several of these, you are probably looking at a company where security is practiced, not just printed:

• A public path for security advisories — a page, a mailing list, release notes that plainly say "this release fixes a security issue" rather than burying it in "miscellaneous improvements."
• A stated way to report vulnerabilities to them, and a tone that treats researchers as allies rather than threats.
• Documentation that admits limits. A hardening guide, a "what this does not protect against" section, honest notes that a feature is off by default and why. Marketing never writes those sentences; engineers do.
• Specificity under questioning. Ask a pointed technical question pre-sales and see who answers. A real answer from someone technical, including an occasional "no," is one of the best signals available. It is the live version of everything this article checks for.
• Security-relevant configurability. Products built by security-conscious teams let you turn things off: protocols, features, interfaces. Products built for demos default everything on.

The counter-signals mirror them. Look for badge walls with no reports behind them, or a perfect breach-free story paired with vague answers. Look for pressure to skip evaluation because a discount expires, or security pages that never once say "no," "off," or "limitation." (The expiring discount, I have noticed, is usually available again the following month.)

When Claims and Reality Disagree

Sooner or later a trial will surface a mismatch: the page says one thing, the product does another. Resist the urge to conclude bad faith immediately — work the sequence. First, check your own reading; security pages describe the newest release and every edition, and you may be testing a different combination. Second, check the documentation; honest products sometimes have stale marketing. Third, ask the vendor, precisely and in writing: "your site says X; in the trial I observe Y; which is correct?"

The response is the real data. A good vendor confirms the discrepancy, explains it, and often fixes the page. That small event tells you a great deal about how they will handle a security report someday. A vendor who re-asserts the claim without addressing your observation has answered a different and more important question. Either way, record the exchange in your assessment file alongside the question-set answers. The scoring habit from the vendor question set — verified, credible, open — applies to marketing claims exactly as it does to questionnaire answers. We have received that email about a page of our own; it was not pleasant, and the page is better for it.

The Skeptic's Habit

None of this requires cynicism. It requires a habit: translate the claim into a fact, find the scope, ask for the evidence, and test what you can touch. Vendors who are doing the work will survive that habit comfortably. Many will visibly relax when they realize they are talking to someone who reads the report instead of the badge. Vendors who are not doing the work will supply you with adjectives, and now you know how to weigh those.

From here, one natural companion is the security questions to ask a transfer vendor, which turns skepticism into a concrete question set. Another is the self-hosted vs SaaS risk trade, where claim-reading meets the biggest architectural choice in transfer tooling. The next time four security pages read like one, you will know which questions make them differ.

Frequently Asked Questions