Encryption remains necessary. It is not the whole problem. A new independent assessment from the Foundation for Defense of Democracies looks at what protects sensitive data after it is already in use, and at the architecture Rixon built to do it.
This approach to data protection beyond encryption focuses on reducing the value of sensitive information when it is exposed.
Rixon Technology · October 26, 2026 · 6 min read
Firewalls, identity, access control, monitoring, and encryption protect paths to data. They do not, by themselves, reduce the value of a readable copy once an authorized or unauthorized party has it. That is the gap a new technical note from the Foundation for Defense of Democracies’ Transformative Cyber Innovation Lab (TCIL) is written around.
The note, Beyond Encryption: Reducing the Value of Exposed Data, looks at what happens after sensitive data is already in use: copied into logs, shared with processors and partners, held in backups, or fed into analytics and AI workflows. Traditional controls still matter. They do not change what an attacker, an insider, or a breached partner can do with a readable value.
What the note examines
The architecture under review is vaultless, keyless pseudonymization. Sensitive fields are replaced with format-compatible substitutes before the data moves downstream. Restoration is not a stored key that works on its own. It requires authorized reconstruction under policy conditions such as role and geography.
This is pseudonymization, not anonymization. The original value can be restored under controlled conditions. It is not permanently removed.
The note is explicit that this approach complements encryption, zero trust, access control, monitoring, and post-quantum migration. It does not replace them.
What the assessment reported
TCIL tested practical questions against an implementation of that architecture. Rixon Technology was the implementation evaluated. The reported results, in the note’s own framing, included:
- The format of sensitive values could be preserved, so downstream systems could continue to operate.
- Unauthorized restoration attempts failed and were logged.
- Authorized, multi-party restoration returned the correct values.
- Intercepted tokens did not reveal the original data under the methods used in the test.
- Access to a token could be revoked by cutting off re-identification, without having to locate every copy.
Those findings are specific to the tested workflow. They are not a claim that every deployment, every field, or every threat model will produce the same result.
“What matters most here is how the testing was done. An independent lab operated the platform directly and tried to break the restoration controls, not us. That they saw unauthorized attempts fail and get logged, and that intercepted tokens didn’t give up the original data, speaks to the architecture we set out to build: recovery is a governed event, not a default capability sitting downstream.”
Justin Hatcher · Co-Founder & Chief Technology Officer, Rixon Technology
What this does not solve
The note is careful about limits. So is this post.
The honest boundaries
- Encryption in transit and at rest still belongs. Tokenization does not replace it.
- This is not a fix for identity, endpoint, or network compromise.
- It is not an AI firewall. It can reduce what sensitive values enter a pipeline. It does not govern model behavior.
- It does not, by itself, satisfy PCI DSS, GDPR, DPDP, or any other regulation. Scope and erasure outcomes depend on how a system is deployed.
- “Vaultless” does not describe what enables recovery. Some vaultless designs still reverse a token with a cryptographic key. The architecture assessed here does not rely on a single stored key or a central vault of mappings.
Where this fits in the stack
It is fair to point out that data-in-use protection already exists. Confidential computing, including hardware-isolated enclaves such as Intel TDX and SGX or AMD SEV-SNP, protects data in memory while it is processed, so that the hypervisor, host OS, and cloud operator cannot read it. Homomorphic encryption and secure multi-party computation allow certain computations to run on protected data without exposing it. These are real, and they are improving.
They also share a boundary. Each protects data at the point of computation, in one place. Confidential computing protects a value inside the enclave; the moment that value leaves the enclave for a database, a log, a partner, or a downstream service, it is readable again. Homomorphic encryption remains, by independent accounts, orders of magnitude slower than plaintext computation and is still considered experimental for most production workloads. Both are narrow, purpose-built tools for a specific processing step.
None of them reduce the value of the readable copy that ends up downstream, in the warehouse, the backup, the partner system, the analytics tool, the AI pipeline. That downstream copy is a different problem, and it is the one a data-layer control is aimed at. These approaches are complements, not competitors. A sound architecture may use more than one.
Why data protection beyond encryption matters
Most modern environments do not keep sensitive data in one place. Payment credentials, account identifiers, and personal data move through processors, wallets, analytics tools, contractors, and AI systems. Each copy is a potential readable value.
If those systems work on substitutes instead of original values, a breach of a partner or a downstream store yields less. Ransomware leverage is lower if the stolen file does not contain the original data. Erasure and access revocation become a control question, not only a delete-every-copy question.
“Every organization we work with is being asked to move sensitive data to more places, more partners, more analytics, more AI, while staying accountable for all of it. An independent look from a lab focused on national-security problems validates the direction we bet on: protect the data itself, so that spreading it costs you less. That is the conversation our customers are trying to have, and it is good to see it taken seriously.”
Dave Johnson · Chief Executive Officer, Rixon Technology
The cost and architecture questions remain. A vault that stores original values still concentrates data, storage, replication, and audit scope. A key-based vaultless design still carries key lifecycle and custody cost. A keyless design moves the residual risk to policy, authorization, and the integrity of the translation path. Those are different bills and different failure modes.
How to evaluate a design like this
The note recommends independent review, bounded pilots, and procurement disclosure rather than adoption by slogan. Useful questions for any vendor, including Rixon:
- If there is no vault, what enables recovery?
- Can a stolen token be reversed offline, or only through a live authorized request?
- Where do original values, mappings, or reconstruction materials appear in memory, logs, or backups?
- Who can authorize restoration, and is that decision logged per request?
- Does the token still reveal fragments or equality that a buyer did not intend?
- What happens on exit?
We published a vendor-neutral checklist for those questions. Use it with every provider.
Compare architectures, not slogans
The six questions above are part of our vendor-neutral evaluation framework.
How Rixon's approach is defined
It is tokenization at the core. Sensitive values are replaced with format-compatible tokens. That tokenization is how pseudonymization is achieved here, rather than through a separate step. The data is pseudonymized by being tokenized.
There is no key and no central vault. What separates this from conventional tokenization is that no vault of original values and no single stored key reverses the tokens. Reconstruction happens only through segmented, policy-governed authorization. That also separates it from pseudonymization approaches that can be reversed by whoever holds the mapping or the key, because there is no single secret to hold.
It supports data minimization. Because values are tokenized at the point of entry and are reconstructable only under policy, the original data is not sitting accessible across downstream systems. On top of that, detokenization events themselves can be governed and masked by role, organization, and other policy conditions.
The result draws on tokenization as the mechanism and keyless, policy-controlled reconstruction as the control. Depending on the deployment and the process, that offers advantages over conventional tokenization and over mapping- or key-based pseudonymization alike.
Other Sources
Encryption still belongs. Reducing the value of the data that remains is a separate control. The FDD note is an independent look at one way to do that. It is an evaluation, not a certification. The findings described are specific to the tested configuration; another deployment would require its own assessment. Organizations remain responsible for complying with applicable regulatory requirements regardless of the technology architecture employed.
Evaluating a tokenization solution?
© 2026 Rixon Technology (PB Analytics, Inc.). Vaultless, keyless tokenization. Chandler, Arizona.