The Vocabulary of Trust Is Broken. Here's a Repair Kit.
The words we use in digital identity are load-bearing. Use the wrong one and the listener walks confidently down the wrong road — and in identity, security, and compliance, most of our everyday words send people the wrong way. This is the eleven-point vocabulary repair kit for anyone building identity infrastructure: data vs information, trust vs proof, authentication vs identity, permission vs authority, compliance vs evidence, disclosure vs predicate. If our language keeps reaching for words that can't be measured, are we building resilience — or performing security?
Words are load-bearing. Use the wrong one and the listener walks confidently down the wrong road — and in digital identity, almost all of our everyday words send people the wrong way. This is the eleven-point vocabulary repair kit for anyone building identity infrastructure. If our language keeps reaching for words that can't be measured, are we building resilience — or performing security?
Years ago I started sorting this field's vocabulary with one line down the middle of the page. On one side sits the human: meaning, judgment, decisions — and trust, which is a feeling humans have. On the other side sits the machine: signals, storage, computation — and proof, which is a property machines can check. Most of the confusion I meet in identity, security and compliance is a word being used on the wrong side of that line.
Here is the repair kit. I've needed every piece of it this year — several times to correct myself.
1. Data is not information
Data sits on the machine side: bytes, records, fields — no human component. Information sits on the human side: it's what data becomes when a person reads meaning into it — and only if they carry the prior knowledge to understand what the data means. The same bytes are information to one reader and noise to another. The two words get swapped daily, and the swap hides who is actually involved. A database holds data. The moment a person looks at it, you don't have a storage question any more — you have a human one.
2. The regulation that proves the point: GDPR
Say the full name slowly: General Data Protection Regulation. The name lives on the machine side of the line. Yet watch where organisations spend their effort, and you'd think it read General Paperwork Protection — consent banners, registers, attestations — while the thing the regulation exists to shield, the person behind the data, gets shielded last.
And here is the structural problem, seen from the line: the toolbox we deploy to "protect data" keeps a human component inside it. Administrators who can query the store. Support staff who can view the records. Reviewers who look at your passport scan. Every one of them sits on the data side of the line — and every one of them has to be trusted, which is a property from the other side. A machine-side protection whose guarantee rests on human-side trust defeats its own concept. That's not a compliance gap; it's a category error — and it's why "trusted, compliant" companies keep leaking. The repair is architectural: build the data side with no human component in it — nothing for an insider to view, nothing for a support agent to be bribed for — and let humans stay on the human side, where being trusted is appropriate. Data protection that works looks like data nobody can look at.
3. "Trusted" is not a property of systems. It's a feeling of people.
We say "trusted supplier", "trusted device", "trusted platform" as if trust were a property of the thing. It's a human-side word: a state of the person relying. The machine-side counterpart is provable — the signature validates or it doesn't. Whenever a design document says a component "must be trusted", read it as: here the architecture gave up and dragged a human-side word across the line. Count those spots. That's your attack surface.
4. "Secure" is not a measurement
Try this thought experiment. The number 5 is stored on your device. The same number 5 is stored on someone else's machine. Are they equally secure? What would you even measure to answer that? "Security levels" as we casually use them are assumptions stacked on assumptions — a feeling with a rating attached.
What can be measured — what universities actually teach and test — sits on the machine side of the line: resilience to attack, which you can probe, quantify and compare; and reliability, which you can engineer and prove statistically. When someone says "this is secure", the honest translation is "I feel safe about this." When someone says "this withstands these attacks and fails at this measured rate", they've said something you can check. Notice which phrasing dominates the conversations you sit in.
5. Authentication is not identity
The most expensive confusion in enterprise security. MFA, SSO, passkeys — authentication proves this is the same account as last time. It says nothing about who is behind it, because nobody ever proved that at the start. Authentication answers "same as before?"; identity answers "who?". If the "who" was never established, you have strengthened the lock on a door you never looked behind.
6. Splitting a key is not the same as fragmenting one
I've used "split" loosely myself, in an article this June — and in identity hardening the two words describe genuinely different designs, both legitimate. Splitting starts from a whole: a complete key exists and is then divided into shares so that no single share can act alone — a respected, proven family of designs. Fragmenting never forms the whole: two processes, blind to each other, each create their own fragment, and the complete key never exists anywhere — not at creation, and not at use either. The fragments never meet. Only the signature comes together. Neither word is a criticism of the other; they simply answer the question "did the whole key ever exist?" differently — and that answer is part of any system's security model, so the word should match the design. My correction here is aimed at my own writing, nobody else's.
7. "Qualified" is not a mathematical property
In European signing, the first question asked is: is this signature qualified? It's a fair question — but notice what kind of question it is. A qualified and an advanced electronic signature can use the very same mathematics. What "qualified" adds is not stronger cryptography; it's a chain of trusted components — certified devices, audited providers, an investment rewarded with a certificate from a recognised platform. That has real value: it buys legal presumption, recognised liability, an answer a court accepts by default. But it is a who-vouches answer, from the human side of the line — not a what-the-math-guarantees answer from the machine side. Both questions matter. Confusing them leads to two opposite mistakes: paying for a legal status while believing you bought better mathematics, or dismissing the legal status because "the math is the same." Know which one you're buying, and why.
8. Permission is not authority
An API key is permission: whoever holds it gets in — the agent you deployed, the copy you forgot, the attacker who found it in a config file. Authority is different: it names who may act, under whose mandate, within what limits, and how that mandate dies. Permission is a machine-side artifact; authority reaches back across the line to an accountable human. AI agents acting on delegated authority need the second thing — and handing them permission while calling it authority is how "the algorithm did it" ends up in front of a regulator.
9. Compliance is not evidence
Compliance attests that a process was followed. Evidence proves that a fact is true. Both matter — but they answer different questions, and the gap between them is where breaches live: a company can be fully compliant in how it verified you and still hold no proof of who you are. When the dispute comes, the auditor accepts attestation; the court wants evidence. Build for the court and the audit takes care of itself. The reverse is not true.
10. Disclosing less is not the same as proving without disclosing
Two things get called "zero-knowledge" in identity, and only one of them ships today. Selective disclosure — showing one field of a credential instead of all of them — is real, standardised, deployable now. Predicate proof — answering "over 18?" with a cryptographic yes/no and revealing nothing else — is where the architecture is heading, and where we're building; it is not on anyone's production menu yet. Vendors blur these because the blur sells. The two-word repair: disclosure is showing less; a predicate is proving without showing. Ask which one you're buying.
11. An AI agent is not a machine identity
We have three identity vocabularies: identity for humans, certificates for machines, tokens for applications. An AI agent acting under a person's delegated authority fits none of them. It is a fourth thing — the phrase is my co-founder Mairi Kutberg's, and it stuck because it's precise. Seen from the line, the agent is the first actor standing on both sides at once: it executes like a machine and acts on a human's mandate. Treat it as a service account with extra steps and everything works — right up to the only question that matters: who is accountable for what it just did? Then the vocabulary gap becomes a liability gap.
A bonus repair from my own comment section
I once wrote that electronic consignment notes become "mandatory across the EU" in July 2027. A reader correctly sharpened me: the regulation obliges authorities to accept electronic freight information — it mandates readiness, not usage. The difference decides what you build first. I keep the correction visible because that's the whole point of this list: precision is not pedantry. In infrastructure, the word is the spec.
The question I'll leave open
Now step back and look at the whole list at once — a pattern shows. The words that dominate our industry's stage — trust, assurance, confidence, secure — all live on the human side of the line: feelings, arbitrary to measure. The words that can actually be tested — proof, resilience, reliability — are the ones you rarely hear in a keynote. I don't claim to know why. So I'll ask it as a genuine question rather than an accusation: if our language keeps reaching for the words that can't be measured, are we building resilience — or performing security?
Draw the line down your own vocabulary. Which of your words is sitting on the wrong side?
More in this cluster
Companion posts on the vocabulary distinctions this article draws:
- What's the Difference Between Hash and Digital Signature? — the crypto primitive versus the surrounding trust chain
- AdES vs QES: Which eSignature Level Does Logistics Need? — same mathematics, different vouching (§7)
- Passkeys, Identity Proofing, and the Cross-Border Gap — authentication is not identity (§5)
- NIS2 Article 21 Identity Evidence — What Auditors Ask For in 2026 — compliance is not evidence (§9)
- Zero-Knowledge Proofs — Where Do They Apply? — disclosure vs predicate (§10)
- What Is Know Your Agent (KYA) and Why Should You Care? — the AI agent as fourth thing (§11)
- How Long Do Digital Signatures Remain Valid? — provable versus trusted, at the archival horizon
Sources
Primary — eIDAS and evidence framework
Primary — data protection
Primary — AI and workforce accountability
Primary — supply-chain and identity
- Directive (EU) 2022/2555 — NIS2 Article 21
- ICAO Doc 9303 — Machine Readable Travel Documents
- NIST SP 800-63-4 — Digital Identity Guidelines
About the author
Gustav Poola is a co-founder of IdentiGate OÜ, a European identity-verification and digital-signature company building on top of chip-anchored identity proofing (ICAO 9303 passport NFC), Advanced Electronic Signatures under eIDAS Article 26, and Advanced Electronic Seals. He writes about the vocabulary and architecture of digital trust — the specific words that sit on the wrong side of the line between what humans feel and what machines can prove, and the engineering repairs that put them back where they belong.