Thales

Overview

Thales is a data security and encryption vendor. Its products help organizations protect sensitive data with hardware security modules (HSMs), central key management, data-at-rest encryption and tokenization. The common thread is simple: keys and secrets should be generated, stored and used in a controlled place, and the data they protect should stay useless to anyone who steals it.

For teams that train or run models on tables, this matters because tables are where the sensitive facts live. Customer records, payments, health codes and employee data sit in rows and columns. A security layer such as the one Thales sells decides who can read those columns, how keys are rotated and how a regulator can be shown proof. This page explains the main product families, how they work, and how they connect to pipelines that feed tabular foundation models. See also HashiCorp Vault, Spark UDF de-identification and Amazon RDS for neighbouring pieces of the same puzzle.

What it is

Thales is a large technology group that works in several fields. In the data protection area it provides a family of products that cover the full life of a cryptographic key and the data the key protects.

The main product families

• Hardware security modules (HSMs). Tamper-resistant devices that generate keys, store them and perform cryptographic operations inside a protected boundary. Keys never leave the device in clear form.
• Key management. A central console that creates, rotates, backs up, retires and audits keys for many systems at once.
• Data-at-rest encryption. Agents or drivers that encrypt files, volumes, databases and cloud storage, with policy deciding which users and processes see clear text.
• Tokenization and format-preserving encryption. Methods that replace a sensitive value, such as a card number, with a surrogate that keeps the same shape.
• Payment security. Specialized HSMs for card processing, PIN handling and payment key hierarchies.
• Cloud and service forms. Key management and HSM capability offered as a managed service, so teams do not run hardware themselves.

Why people buy it

Regulated sectors have rules about where keys live and who may touch them. Banks, insurers, hospitals, telecom firms and public bodies often need proof that keys are held in certified hardware and that access is logged. A vendor with certified devices and an audit trail makes that proof easier.

Where it came from

The story of this product line is a story of mergers. Several well-known security brands were combined over the years. Thales bought the digital security company Gemalto in 2019, and with it came the lineage of SafeNet HSMs and other data protection products. Earlier acquisitions had brought in encryption brands used for file and database protection. The result is a portfolio that spans devices, software agents and cloud services.

The standards behind the products

The field itself grew out of a few durable ideas.

• Public key cryptography in the 1970s made it possible to share secrets without a prior shared key.
• Hardware modules appeared when banks needed to protect PIN keys in networks of ATMs.
• Federal and international standards, such as the FIPS 140 series and Common Criteria, gave buyers a shared way to judge devices.
• PKCS#11 and later KMIP defined common programming interfaces, so software could talk to many vendors.
• Cloud adoption pushed the market toward "bring your own key" and "hold your own key" models.

From banks to data lakes

Early HSM use was narrow: certificate authorities and payment switches. As more data moved into lakes, warehouses and machine learning platforms, the same ideas spread. Key management for databases, tokenization for analytics and encryption for object storage became everyday topics. Today the conversation includes model training data, because a leaked training table is as damaging as a leaked database.

How it works

The simplest way to picture it is a bank vault inside a building. The building is your application. The vault is the HSM. People can ask the vault clerk to sign a document or unlock a box, but nobody can walk out with the master key.

Step 1: Keys are generated inside protected hardware

An HSM has a hardware random number generator and a secure boundary. When you ask it to create a key, the key is born inside. Everyday analogy: a notary stamps a paper in a locked room and only hands you the stamped paper, never the stamp.

Step 2: Keys are organized in a hierarchy

Real systems rarely use one key for everything. They use a tree.

• A root key lives in the HSM and almost never moves.
• Key encryption keys (KEKs) are protected by the root key.
• Data encryption keys (DEKs) are wrapped by KEKs and used on actual data.

This is called envelope encryption. Think of a safe deposit box. The big key opens the room, the small keys open individual boxes, and each box holds something different.

Step 3: A key manager sets policy

A central key manager holds the metadata: who owns a key, what it may be used for, when it expires and which clients may request it. Applications connect through standard interfaces. The manager records every request, which gives an audit trail.

Step 4: Agents or APIs encrypt and decrypt

There are two common styles.

• Transparent encryption. An agent on a server intercepts file or database access. Authorized processes see clear text. Everyone else, including a stolen disk, sees noise.
• Application-level calls. The application asks a service to encrypt or decrypt a field, or to tokenize a value, and receives a result back.

Step 5: Tokenization swaps values for surrogates

Tokenization replaces a real value with a token. A lookup (in a protected vault or computed by a keyed method) can map it back. Analogy: a coat check. You hand over a coat and get a numbered ticket. The ticket is worthless to a thief, and the cloakroom can turn it back into the coat.

Step 6: Rotation, backup and retirement

Keys age. Good practice rotates them on a schedule and after any suspected exposure. The key manager re-wraps data keys, schedules re-encryption where needed, and destroys old keys on a planned date. Backups of key material are wrapped and stored in secure form so a lost device does not mean lost data.

Step 7: Everything is logged

Each key use leaves a record. Auditors can ask: who unlocked this column, when, from where? Logs are often sent to a separate monitoring system so that an attacker who controls one server cannot erase the trail.

How it looks on a table

Imagine a customer table with columns for name, national ID, email, balance and signup date. A policy might say:

• national ID is tokenized with format preservation
• email is encrypted at field level
• name is masked for analysts
• balance and signup date stay clear for modelling

The same table, shown to three roles, produces three different views. That is the practical result of key management and policy.

Deployment models in more detail

On premises appliances

A rack-mounted HSM sits in your own data centre, often in pairs for resilience. You control the physical room, the network and the staff. This gives the strongest sense of ownership, but you carry the cost of power, cooling, spare units and firmware updates.

Cloud-hosted HSM service

A provider runs dedicated hardware for you. You get an isolated partition and your own administrators. The provider keeps the device alive, and you keep control of the keys. This suits teams that want certified hardware without a hardware team.

Key management as a service

At the lightest end, you call an API for key operations and never see a device. Setup takes hours instead of weeks. The trade-off is that you rely on the provider for availability and for the trust boundary.

Hybrid designs

Many firms keep the root key on premises and let cloud services use derived keys. If the link breaks or the root key is revoked, the cloud copies stop working. This is sometimes called a kill switch for data.

What happens during a single field decrypt

Follow one request from start to end.

1. A data job needs to read the email column.
2. The job presents its workload identity to the key manager.
3. The key manager checks policy: is this identity allowed to decrypt email in this table?
4. If yes, it returns a short-lived data key, or performs the decrypt itself and returns clear text.
5. The job uses the value in memory and drops it.
6. The request is written to the audit log with the identity, the key name, the time and the outcome.

At no point does the root key leave the HSM. At no point is the audit log optional.

Latency and throughput in plain numbers

Imagine a job that must decrypt 50 million values. If each call to a remote service took five milliseconds, calls made one after another would take roughly 250,000 seconds, which is almost three days. Batching 1,000 values per call cuts the number of round trips by a factor of 1,000. Fetching one data key and decrypting locally cuts it further. The lesson is that crypto design for tables is mostly about batching and key caching, not about raw cipher speed.

Common compliance drivers

This table is a general orientation. Always check the exact text of the rule that applies to you.

Post-quantum readiness

Researchers expect that large quantum computers could break some public key methods in use today. Standards bodies have been selecting new algorithms for this reason. Key management vendors, including this one, discuss crypto agility: the ability to swap algorithms without rebuilding every system. For long-lived data, such as medical records kept for decades, planning for agility is wise. Symmetric ciphers with long keys are considered much more resilient.

Questions to ask when choosing a key management setup

• Which regulations bind us, and do they name specific device certifications?
• Who must be unable to see the data, including our own administrators?
• How many systems need keys, and which interfaces do they speak?
• What is the failure plan if the key service is unreachable?
• How do we prove to an auditor that a key was never exported?
• What does a restore from backup look like, and when did we last practice it?

A short checklist for a tabular data project

• [ ] Every table has an owner and a sensitivity label.
• [ ] Sensitive columns have a named protection method.
• [ ] Keys are held outside the data store.
• [ ] Training jobs use a dedicated identity with least privilege.
• [ ] Logs of key use are sent to a separate system.
• [ ] A tested rotation procedure exists.
• [ ] A comparison of model quality with and without protection is on file.

Separation of roles in a key service

The security officer

Defines policy, approves new keys and reviews logs. This person should not be able to read business data.

The data owner

Decides who in the business may see which columns. This person does not touch keys.

The platform engineer

Runs the service and the pipelines. This person can deploy but cannot approve policy changes alone.

The auditor

Has read-only access to logs and configuration, and nothing else.

Four roles, four keys to the same lock. The design means no single stolen account is enough to expose a table.

Key concepts and terms

A worked example

This example shows a safe pattern for preparing a table for modelling. It uses a placeholder client for a key service. Names and hosts are fake.

The scenario

A table loans has these columns: customer_id, national_id, email, income, loan_amount, default_flag. The goal is to build a default-risk model. The model needs income and loan_amount. It does not need the national ID or email, but the join key customer_id should remain stable.

The plan

1. Tokenize national_id with format preservation, so downstream checks on length still work.
2. Encrypt email at field level. Analysts cannot read it.
3. Keep customer_id as a keyed pseudonym so that joins still work.
4. Leave numeric columns untouched.

Code sketch

import hashlib
import hmac
import pandas as pd

# Placeholder: in real life the secret comes from a key service,
# not from source code and not from an environment file in git.
def fetch_pseudonym_key() -> bytes:
    # example.internal is a fake host used only for illustration
    # A real call would authenticate and request a key by name
    return b"fetched-from-key-service"

KEY = fetch_pseudonym_key()

def pseudonym(value: str) -> str:
    mac = hmac.new(KEY, value.encode("utf-8"), hashlib.sha256)
    return mac.hexdigest()[:20]

df = pd.read_parquet("s3://example-bucket/loans/raw.parquet")

df["customer_id"] = df["customer_id"].astype(str).map(pseudonym)
df = df.drop(columns=["national_id", "email"])  # not needed for the model

df.to_parquet("s3://example-bucket/loans/model_ready.parquet")

What the sketch teaches

• The key is fetched at run time and never stored with the data.
• A keyed hash gives stable pseudonyms. Without the key, the pseudonym cannot be recomputed by an attacker with a guess list.
• Columns that the model does not need are removed, not just hidden. The safest field is the one that is absent.

A numeric walk-through of envelope encryption

Suppose you have 1,000 files. With one master key you would need to re-encrypt all 1,000 files when you rotate it. With envelope encryption, each file has its own DEK. The DEKs are wrapped by one KEK. To rotate the KEK, you unwrap and rewrap 1,000 small keys, which is fast, and you leave the big files alone. That is why the hierarchy exists.

Policy sketch in YAML

policy:
  name: loans-analyst-read
  resource: table/loans
  rules:
    - column: national_id
      action: deny
    - column: email
      action: mask
    - column: income
      action: allow
    - column: loan_amount
      action: allow
  audit: true
  approvers_required: 2   # for any change to this policy

This is an illustration, not a product schema. The point is that data access can be described in a short, reviewable file.

Strengths and limitations

Strengths

• Hardware root of trust. Keys generated and used inside certified devices are hard to extract.
• Centralized control. One place to see and manage keys across databases, files and clouds.
• Audit and compliance. Logs, certifications and separation of duties support regulated workloads.
• Choice of deployment. On premises, in a cloud service or in a hybrid form.
• Standards support. KMIP and PKCS#11 reduce lock-in at the interface level.
• Format-preserving options. Tokenization can keep length and shape so legacy systems keep working.

Limitations

• Cost and effort. Hardware, licences and skilled staff are real costs for small teams.
• Latency. Each call to a remote crypto service adds a delay. Field-level encryption on billions of rows needs careful batching and caching.
• Operational weight. Key ceremonies, backups and quorum rules add process.
• It protects data, not meaning. Encrypted or tokenized columns cannot be used for most analytics unless the method preserves structure.
• Not a cure for bad access control. If an authorized user is compromised, encryption does not help.
• Complexity for machine learning. Models need patterns. Aggressive protection can remove the very signal you want to learn.

How it compares with alternatives

These choices are not exclusive. Many mature stacks use an HSM for the root of trust, a secrets service for applications, cloud keys for storage and Spark jobs for bulk de-identification.

Role in tabular foundation models

Tabular foundation models learn from raw tables: rows, columns, mixed types, missing values, and often no reliable column names. They are pre-trained on synthetic or real tables and then used through in-context learning, where a few labelled rows act as examples at prediction time. See /model/architecture and /model/research for how such models are built. A security layer touches this world in several concrete ways.

Protecting the tables that feed the model

Real tables used for pre-training, fine-tuning or continual learning often contain personal or commercial data. Encryption at rest and strict key control keep those tables safe in storage. Only the training job, running under a controlled identity, gets the keys to read them.

Controlling what the model sees

A model that reads rows should see the columns it needs and nothing more. Policy-based masking and tokenization can be applied before data reaches the training or inference service. Because foundation models can work without column names, they can often cope with columns that have been renamed to neutral labels, which makes de-identification easier.

What survives protection

Different protection methods keep different amounts of signal.

A column with equality preserved can still help a model. For example, a pseudonymized category can be used in sector or semantic classification, because the model only needs to learn that equal tokens mean equal things. It cannot learn from the meaning of the original text, since that meaning is gone.

Missing values and imputation

Masking can create artificial missingness. If a column is hidden for some roles, the table seen by those roles has holes. Imputation, the task of filling in missing cells, can then be run on the permitted view. Be careful: imputing a sensitive column from other columns can re-create information you intended to hide. Treat imputation outputs as sensitive if they approximate a protected field.

Anomaly detection and audit

Anomaly detection on tables can also run on key-use logs. Unusual volumes of decrypt calls, odd hours or new clients are good signals. This is a use of tabular models on security data itself.

Continual learning

When a model is updated on new data over time, each new batch needs the same protection steps. Key rotation matters here: if the pseudonym key changes, the same entity gets a new id and the model can no longer link old and new rows. Plan rotation so that mapping stays consistent, or use a versioned pseudonym scheme.

Synthetic data as a safety valve

Pre-training on synthetic tables reduces exposure, since synthetic rows contain no real person. For fine-tuning on real data, security controls still apply. Teams often use a layered view: synthetic pre-training, then protected real data for adaptation, then evaluation on held-out protected data. Results from such models can be reviewed on /model/benchmarks.

Where this fits in a pipeline

1. Data lands in object storage such as Amazon S3, encrypted with managed keys.
2. A Spark job applies masking and tokenization.
3. The cleaned table is stored in a lakehouse format such as Delta Lake.
4. A training or inference service reads it under a limited identity.
5. Logs from every step flow to monitoring.

This description is generic. It does not claim that any specific product has a built-in connector to any specific model.

Practical guidance and best practices

Start with a data map

List the tables and columns, mark which are sensitive, and note why each is needed. You cannot protect what you have not found. A short classification such as public, internal, confidential and restricted is enough to begin.

Prefer removal over protection

If a column is not needed for the model, drop it. Removal is cheaper and safer than encryption.

Keep keys away from data

Never store keys beside the data they protect. Never store them in code, notebooks or shared drives. Fetch them at run time from a key service using a workload identity.

Use envelope encryption

Use a small number of KEKs and many DEKs. This makes rotation cheap and limits the damage from a single exposure.

Rotate on a schedule and after incidents

Write down rotation intervals. Test the rotation process in a staging environment first. Rotation that has never been rehearsed tends to fail on the day it is needed.

Separate duties

The person who administers keys should not be the person who reads the data. Require more than one approver for sensitive changes.

Cache with care

If a pipeline decrypts millions of values, cache data keys in memory for a short time instead of calling the key service per row. Set a short time to live and clear caches when jobs end.

Choose the right method per column

• Identifiers you never need: remove.
• Identifiers you need for joins: keyed pseudonym.
• Values that must keep their shape: format-preserving token.
• Values that must stay secret even from analysts: random encryption.
• Numbers you want to model: keep clear, or generalize if risk is high.

Test the protected view

Train a baseline model on the protected table and compare it with a model on the clear table, where policy allows such a comparison inside a secure area. If accuracy collapses, one of the protections removed needed signal.

Plan for failure

Back up key material in wrapped form. Document recovery. Run a restore drill. A key that cannot be recovered means data that cannot be recovered.

Monitor key use

Alert on spikes in decrypt requests, new client identities, use from unusual networks and failed attempts. Feed these logs to a detection system.

Keep documentation simple

A one-page diagram showing where keys live, who can use them and how data flows is worth more than a long policy nobody reads.

Common mistakes

• Treating encryption as the whole plan. Access control, logging and data minimization matter as much.
• Hard-coding secrets. Keys in code or notebooks end up in repositories.
• One key for everything. A single exposure then affects every system.
• Forgetting backups of keys. Lost keys mean lost data.
• Skipping rotation tests. Rotation fails on the first real attempt.
• Tokenizing without thinking about joins. Different tokens for the same entity in different tables break analytics.
• Hashing low-entropy values without a key. A plain hash of a phone number or a small id space can be reversed by guessing.
• Ignoring side channels. Column names, row counts and file sizes can leak information even when values are protected.
• Leaving test data real. Copies of production data in test systems often have weaker controls.
• Over-masking. Removing every informative column leaves nothing to model.
• Under-masking quasi-identifiers. Combinations such as postal code, birth date and gender can identify people even without names.
• Letting model outputs leak. Predictions or generated rows can reveal training data if the model memorizes rare records.

Frequently asked questions

What does Thales do in data security?

Thales provides products for protecting sensitive data: hardware security modules that hold and use keys, key management software that controls many keys centrally, encryption agents for files and databases, and tokenization for replacing sensitive values. The goal is to keep keys under strict control and make stolen data unreadable.

What is a hardware security module?

A hardware security module is a tamper-resistant device that generates keys, stores them and performs cryptographic operations inside a protected boundary. Applications send data in and receive results back, but the key never leaves the device in clear form. It is the usual place for the root of a key hierarchy in regulated environments.

What is the difference between encryption and tokenization?

Encryption transforms data with a key and can be reversed by anyone holding the key. Tokenization replaces a value with a surrogate that has no mathematical link to the original, and the mapping is kept in a protected system or computed by a keyed method. Tokenization is often chosen when the output must keep a fixed shape, such as a card number length.

Is tokenized data still personal data?

It depends on the law and on how the mapping is protected. Under many privacy rules, pseudonymized data is still regarded as personal data because it can be linked back with extra information. True anonymization is a higher bar. Treat tokenized tables as sensitive unless a legal review says otherwise.

Can I train a machine learning model on encrypted columns?

Randomly encrypted columns carry no usable signal, so a model cannot learn from them. Pseudonymized or tokenized columns keep equality, so they can serve as categories or join keys. Numeric columns usually need to stay clear or be generalized into bins if the model is to learn from their values.

Does protecting data hurt tabular foundation model accuracy?

It can, if the protection removes signal the model needs. Removing identifiers that the model never needed usually costs nothing. Masking informative numeric or categorical columns can reduce accuracy. The best approach is to protect what is truly sensitive, keep what is needed and measure the effect on a held-out set.

How does key rotation affect pseudonyms?

If a pseudonym is computed with a key, changing the key changes every pseudonym, and rows from different periods can no longer be linked. Plan for this by versioning the scheme, keeping a controlled mapping for a transition period, or rotating keys only at planned retraining points.

How is this different from a secrets manager?

A secrets manager stores and hands out credentials such as passwords and tokens, and often offers encryption services as well. A hardware-backed key management system focuses on strong control of cryptographic keys, certified devices and audit. Many organizations use both, with the hardware holding the root key and the secrets manager serving applications. See HashiCorp Vault for the software-first side.

Where should I apply de-identification in a data pipeline?

Apply it as early as practical, ideally at ingestion, before data spreads to many copies. Doing it in the processing engine, for example with Spark UDF de-identification, keeps raw values out of downstream tables, notebooks and training sets.

Do I need an HSM for a small project?

Usually not. A managed cloud key service or a software secrets system is often enough for small, low-risk projects. An HSM becomes attractive when regulation demands certified hardware, when the data is highly sensitive or when you must prove exclusive control of keys.

Glossary

• Audit trail: A record of who did what and when, kept so that it is hard to alter.
• Bring your own key: A model where the customer supplies or controls the key used by a cloud service.
• Certificate authority: A trusted party that issues digital certificates.
• Cipher: An algorithm for encrypting and decrypting data.
• Data encryption key (DEK): A key used directly on data.
• Data minimization: Collecting and keeping only the data that is needed.
• De-identification: Removing or altering identifying details in data.
• Envelope encryption: Wrapping data keys with a higher-level key.
• FIPS 140: A family of standards for cryptographic modules.
• Format-preserving encryption: Encryption whose output has the same format as the input.
• HSM: Hardware security module, a protected device for keys.
• Key encryption key (KEK): A key that wraps other keys.
• Key ceremony: A formal, witnessed procedure for creating or restoring a root key.
• KMIP: A protocol for communication between key managers and clients.
• Pseudonymization: Replacing identifiers with consistent surrogates.
• Quasi-identifier: A field that does not identify someone alone but can in combination.
• Quorum: The minimum number of approvers required for an action.
• Root of trust: The base component whose security everything else relies on.
• Tokenization: Replacing a sensitive value with a surrogate token.
• Tamper evidence: Features that show whether a device has been opened or altered.
• Workload identity: An identity given to a running program instead of a person.

Summary

Thales is a data security vendor known for hardware security modules, key management, encryption and tokenization. These tools put keys in controlled hardware, organize them in hierarchies, apply policy to who sees which column and keep an audit trail. For tabular work, they decide how sensitive tables are stored, which columns a pipeline or model may read and how identifiers are replaced. Good practice is to remove what you do not need, protect what you must keep, fetch keys at run time, rotate on a schedule and measure the effect of protection on model quality. Used with secrets services, databases and Spark pipelines, this layer lets teams use real tables for tabular foundation models while keeping control of the data. For the model side of the story, see /model/research, /model/architecture and /model/benchmarks.

Related

It belongs to Data protection in my stack, under Data engineering and lakehouse. Others in the same group: