Vague security language trains buyers to accept confidence instead of evidence. Why familiar claims fail, what precise product security communication looks like, and how vendors can make scrutiny possible.
Part 5 of 5 in Building Signet
“Military-grade encryption.” “Zero-knowledge architecture.” “Bank-level security.” “Secure enclave protection.”
These phrases appear all over the App Store listings for security products, and most of them are meaningless, misleading, or too vague to be useful. The damage they do reaches well beyond the individual product that deploys them. The argument here is not that the phrases are dishonest, though several are. It is that they are structurally harmful to the security industry, because they train buyers to accept claims instead of demanding evidence. Once buyers have been trained that way, every security product – including the ones with real technical substance behind their claims – has to compete in a market where marketing language is weighed on the same scale as engineering.
What the phrases actually mean
“Military-grade encryption” usually means AES-256, if it means anything specific at all. AES-256 is required in NSA commercial solutions protecting National Security Systems up to Top Secret, and it is also the routine choice across banking apps, messaging apps, cloud storage, and password managers. It is the default. Calling it “military-grade” is accurate in the way that calling a car’s steel body panels “aerospace-grade” is accurate: technically defensible, practically meaningless, and designed to imply that something ordinary is exceptional.
“Zero-knowledge” has been stretched to cover at least three distinct things. In cryptography it refers to a specific class of proof systems, where one party proves knowledge of a value without revealing the value. In cloud-storage marketing it means the provider never sees your plaintext, because encryption happens client-side. In some other contexts it is used to mean roughly “we do not log what you do”. These are not the same thing, and a product that claims “zero-knowledge architecture” and means client-side encryption is not using the term in the proof-system sense. That matters, because zero-knowledge proofs are a specific and powerful primitive, and conflating them with “we hash your password before sending it” teaches people the wrong mental model.
“Bank-level security” means nothing at all. Banks vary enormously in their security practices and have been breached repeatedly. The phrase works because banks feel secure, not because they demonstrably are.
“Secure Enclave” is more interesting, because it is a real thing – a dedicated secure subsystem in Apple hardware – and it is legitimately valuable for key storage. The misuse is not in invoking it but in using it to imply more than it delivers. Every recent iPhone has a Secure Enclave; the phrase describes the platform, not the application’s security architecture. An app that stores API credentials in UserDefaults is running on a device with a Secure Enclave. Whether the app uses it for anything meaningful is exactly what the label lets you skip checking.
Why this damages the industry
The immediate damage is to buyers. Someone who reads “military-grade encryption” and “zero-knowledge architecture” in two different App Store listings cannot use those phrases to tell the products apart. They are present in both because they are effective marketing, not because they are informative, and the buyer is left with no signal.
The second-order damage is what this does to accurate claims. A product that describes its encryption as “AES-256-GCM with Argon2id key derivation, 128 MiB memory cost, and a 16-byte random salt per export” is giving useful information. A security-conscious buyer can evaluate it: whether the parameters are appropriate, whether the algorithm choices are current, whether the implementation is open source and auditable. But in a market full of “military-grade” and “bank-level”, that specific, verifiable description can look less impressive than the vague one, because buyers have been trained to respond to confident language rather than precise language. This is not theoretical. It is one reason security journalists approach product claims sceptically, and rightly; it is also why products with serious cryptographic credentials have to overcome the same prior probability of marketing noise as products with none.
The third damage is to the security-engineering profession. When marketing language becomes the primary signal buyers use, the incentive for engineering teams shifts towards making claims that read well rather than claims that are accurate. This is not unique to security – it is a general feature of markets with information asymmetries – but it is particularly corrosive in a domain where the gap between the claim and the implementation is usually invisible until something goes wrong.
What verifiable looks like
There are four things a security product can do that are verifiable.
The first is an open-source core. If the cryptographic implementation is public, anyone can read it, and the claim “we use AES-256-GCM with a 96-bit random nonce” becomes verifiable because you can look at the code and confirm it. Claims about closed-source implementations are not verifiable by users; they are claims of trust.
The second is a published independent audit. Not “available on request” – published. An audit that exists but is not public is a document for the vendor’s benefit, not the user’s. A published audit, with named assessors, a documented scope, and finding summaries, is a verifiable claim. It can be wrong, it can miss things, it can be limited in scope – but it is a fact about the product an adversarial reader can examine, and “adversarial examination is possible” is exactly the bar verifiable claims have to clear.
The third is binary analysis in continuous integration. If you claim no third-party analytics, no telemetry, no data collection, you can prove it: scan the production binary for known SDK signatures and fail the build if you find them, then publish the scan in your release notes or CI logs. This is not difficult, and it provides a verifiable audit trail for a claim that is otherwise pure assertion.
The fourth is App Store and Play Store privacy labels that match reality. Apple and Google require developers to declare what data an app collects and make the developer responsible for the accuracy of that declaration. The labels are publicly visible and can be tested against the binary, network behaviour, and SDK footprint. A privacy label reading “no data collected” for an app with a Firebase SDK integration is a specific, falsifiable claim that happens to be false – which is worse than saying nothing at all. It is an affirmative misrepresentation, and it trains users to ignore privacy labels.
The pattern that works
The products that earn technical credibility in the security community tend to share one characteristic: they describe their security model with enough specificity that a reader can identify what would have to be true for the claims to be false. This is not the same as providing overwhelming technical detail. It is precision rather than volume. “We use AES-256-GCM” is precise and verifiable; “military-grade encryption” is neither. “Biometric authentication opens a session with a configurable timeout, and secrets are cleared when the session expires” is precise; “biometric-protected” is not, because it does not say what biometrics protect, when, or what happens when the protection window closes.
Describe the security model with enough specificity that a reader can work out what would have to be true for the claims to be false. Precision invites scrutiny, and that is the point: a product that invites scrutiny is claiming its security model can withstand examination, whilst a product that leans on marketing language is claiming the examination will not happen.
The argument for precision is not that it always wins in the market. It frequently does not, at least in the short term. It is that the industry only improves if buyers learn to demand precision and engineers learn to provide it. Every product that publishes a real security model, with honest scope and honest limitations, makes it slightly harder for the next one to get away with “military-grade”. That is a reason to do it even when it is not the optimal marketing choice, because the security industry’s long-term credibility depends on it.
Attomus builds security products and advises government and defence organisations on security architecture. These principles inform how we document Signet and our other products.
Attomus Signet — offline 2FA, on the App Store and Google Play. Read the Signet assurance record.