Format-Preserving Encryption for Data Masking, Explained

In February 2025, NIST published the second public draft of SP 800-38G Revision 1 — the federal standard governing format-preserving encryption — and made a change with real consequences for anyone using FPE in production: it removed FF3 entirely. A cryptanalytic attack on the tweak schedule, described by researcher Beyne, affected both FF3 and its successor FF3-1, while FF1 remained unaffected (NIST CSRC). That leaves FF1 as the only NIST-approved FPE method going forward, with a required minimum domain size raised to one million and floating-point arithmetic explicitly disallowed to close off a class of implementation bugs first flagged by researcher Bleichenbacher in an earlier Bouncy Castle implementation (NIST CSRC). If your masking program relies on FPE, this is exactly the kind of standards change that should trigger a review of what method you're actually running.

What format-preserving encryption actually is

NIST defines FPE as a mode of operation for an approved block cipher that transforms data formatted as a sequence of symbols — decimal numerals, for example — so that "the encrypted form of the data has the same format, including the length, as the original data." An FPE-encrypted nine-digit SSN comes out as another nine-digit numeral string (NIST SP 800-38G). Under the hood, both FF1 and the now-retired FF3 built this behavior using a Feistel structure — the same general construction underlying the old Data Encryption Algorithm — wrapped around a 128-bit-block AES cipher (NIST SP 800-38G). The practical effect: a 16-digit card number encrypts to a different, but still valid-looking, 16-digit number, and an SSN like 123-45-6789 might become 529-38-1746 — same length, same character set, same field-validation behavior (Tonic.ai).

That distinguishes FPE from traditional block-cipher encryption, which outputs binary ciphertext with a different length and character set than the input — the reason NIST built FPE in the first place was to let organizations "retrofit" encryption onto legacy applications and database schemas that can't tolerate a field changing shape (NIST CSRC). It also distinguishes FPE from irreversible masking techniques like hashing or static substitution: FPE is still encryption, meaning the transformation is mathematically reversible by anyone holding the key (DataStealth).

FF1, FF3, and why NIST killed one of its own standards

When NIST first published SP 800-38G in March 2016, it approved two methods — FF1 and FF3 — as the standardized way to perform FPE, both built as Feistel-based AES modes (NIST SP 800-38G). That didn't hold up. Researchers identified vulnerabilities tied to small domain sizes, prompting NIST to first raise the minimum domain requirement for both methods to one million entries, then — after researcher Beyne demonstrated a tweak-schedule weakness affecting FF3 and its patched successor FF3-1 — remove FF3 from the standard altogether in the 2025 draft revision (NIST CSRC). FF1 survived because its round function derives the tweak differently and wasn't susceptible to the same attack (Wikipedia, citing NIST).

The practical difference between the two methods, historically, was flexibility versus speed: FF1 supported a wider range of data lengths and more flexible tweak sizes, while FF3 offered higher throughput because it ran eight Feistel rounds instead of FF1's ten (NIST SP 800-38G). With FF3 gone, any implementation still running it — or an unpatched FF3 rather than FF3-1 — is running a cryptographic method NIST no longer specifies, which is a real compliance and security exposure for card-data and health-data pipelines built years ago on the original 2016 standard (LinkedIn, Wias Issa).

How FPE differs from tokenization and irreversible masking

Three techniques get lumped together constantly, but they behave differently under the hood:

• FPE encrypts a value using a key so the ciphertext is mathematically related to the plaintext and shares its format — a phone number might become a different, valid-looking phone number (ALTR).

• Tokenization replaces a value with a surrogate token that has no mathematical relationship to the original — recovering the real value requires a lookup in a token vault, not a decryption key (DataStealth).

• Irreversible masking (hashing, redaction, static substitution) doesn't preserve a reversible path back to the original at all.

The distinction matters legally, not just technically. Reversible techniques — tokenization and FPE alike — are pseudonymization under GDPR Article 4(5) and the resulting data remains personal data in scope of the regulation; irreversible masking can potentially reach true anonymization and fall outside GDPR's scope, but only if re-identification is no longer reasonably likely (FakeName Generator, citing GDPR). If your masking program needs a defensible "this isn't personal data anymore" position, FPE alone typically won't get you there.

Where FPE earns its place: PCI DSS and test-environment compatibility

FPE's core selling point shows up clearly in payment card data. PCI DSS Requirement 3 mandates that stored primary account numbers be rendered unreadable, accepting strong cryptography, truncation, tokenization, or hashing as valid methods (ComplyGuide). FPE satisfies that requirement while keeping the PAN's 16-digit format intact, which means downstream systems — fraud scoring, transaction auditing, reporting — keep working without code changes to accommodate a differently-shaped field (Tonic.ai). Prime Factors, an application-level data protection vendor whose EncryptRIGHT product uses FPE, notes that PCI DSS 4.0's push toward "application-level data protection" and format-preserving encryption reflects an explicit design goal of protecting cardholder data "while maintaining its original structure to enable secure processing" (Prime Factors).

FPE's determinism is what makes it useful for test and QA environments specifically: the same input always produces the same encrypted output under a given key and tweak, which preserves referential integrity across joined tables — a masked customer ID or account number stays consistent across every system that references it (Tonic.ai). That's also why FPE shows up in PCI DSS 4.0 non-production data workflows: format-preserving static masking lets QA and analytics teams work with realistic-looking data without ever exposing live PANs, satisfying the standard's ban on using real cardholder data in test and development environments (Accutive Security).

The technical limitation Gartner keeps flagging

FPE is not a drop-in replacement for a dedicated data masking platform, and Gartner has been explicit about why. As cited by Prime Factors from Gartner's research on data masking, "vendors frequently position FPE as a complete alternative to DM products. However, compared with leading DM products, the options for adjusting the output of FPE products are limited" (Prime Factors, citing Gartner). Gartner separately frames data masking as "a crucial component of data security hygiene," serving both secure test-data creation and late-binding access control alongside dynamic data masking, field-level authorization, FPE, and tokenization — positioning FPE as one tool in that stack, not a substitute for the stack itself (Prime Factors, citing Gartner).

Gartner's Hype Cycle research also flags the operational risk that comes with FPE's reversibility: "encryption keys not managed by resilient life cycle best practices and EKM [Enterprise Key Management] could lead to the loss of larger amounts of data if the encryption keys are lost" (Prime Factors, via PRWeb). Gartner's recommendation is to deploy and manage FPE as part of a centralized enterprise key management system with strong crypto-agility, rather than letting individual platforms manage keys natively outside security team control (Prime Factors, via Cision). In other words: FPE's biggest technical limitation isn't the cryptography itself — FF1 is a sound, NIST-vetted algorithm — it's that most FPE tools offer far less flexibility in how the masked output looks and behaves than a purpose-built masking platform does, and the key management burden doesn't disappear just because the field still looks right.

A practical framework for deciding when to use FPE

1. Identify whether the field has hard format constraints. If a downstream system validates length, character set, or checksum logic (Luhn checks on card numbers, for example), format-preservation isn't optional — it's the whole reason to consider FPE over standard encryption (Datasparc).

2. Confirm you actually need reversibility. If no legitimate process ever needs the original value back, tokenization or irreversible masking usually carries less legal and operational risk than encryption that anyone with the key can reverse (DataStealth).

3. Verify you're running FF1, not a legacy FF3 implementation. Given NIST's removal of FF3 from the draft standard, any pipeline still running FF3 or FF3-1 should be migrated or re-evaluated against current guidance (NIST CSRC).

4. Put key management on equal footing with the encryption itself. Gartner's guidance is specific: manage FPE keys through centralized enterprise key management with crypto-agility, not through whatever key handling a single platform provides natively (Prime Factors, via Cision).

5. Test referential integrity across every connected system before rollout. FPE's determinism preserves joins and foreign-key relationships automatically, but only if the same key and tweak are applied consistently everywhere the value appears (comforte).

6. Layer FPE with monitoring, not instead of it. Gartner recommends organizations "monitor and audit all user and administrator access to sensitive data, even when FPE is deployed" — reversible encryption is not a substitute for access controls (Prime Factors, via PRWeb).

Financial services considerations

PCI DSS 4.0 became fully mandatory on March 31, 2025, and Requirement 6.5.4 explicitly bans using real production account data — including PANs — in test or development environments, with no exception for internal or access-restricted systems (Accutive Security). FPE can help satisfy the related Requirement 3 obligation to render stored PANs unreadable, but note that self-managed encryption alone doesn't reduce PCI scope — the systems holding encrypted cardholder data, and anyone who holds the decryption keys, generally remain in scope for assessment unless a validated third party retains exclusive control of those keys (PCI Proxy). PCI DSS 4.0 also now requires separate, unique cryptographic keys for production versus test environments (Requirement 3.6.1.1), which directly constrains how an FPE key can be reused across a masking pipeline (Network Intelligence, PCI DSS 4.0 guidance).

A quick checklist

• Does the field you're protecting have format or checksum validation downstream that would break under standard encryption?

• Do you actually need to reverse the value later, or would irreversible masking or tokenization carry less risk?

• Is your FPE implementation running NIST-approved FF1, or a legacy FF3/FF3-1 build that NIST no longer specifies?

• Are your FPE keys managed through centralized enterprise key management with documented rotation and crypto-agility?

• Have you tested that masked values preserve referential integrity across every connected system, not just the one you masked first?

The bottom line

Format-preserving encryption solves a real, narrow problem: keeping a masked value's shape intact so legacy systems, validation logic, and referential joins keep working. NIST's FF1 is the vetted way to do it, and PCI DSS environments lean on it for exactly that reason. But Gartner's core caution stands — FPE tools give you far less control over the masked output than a dedicated masking platform, and the reversibility that makes FPE useful also makes key management a single point of failure if it's not centrally governed.

C² Data Privacy Platform discovers sensitive data across production and non-production systems and applies the right masking technique automatically — including format-preserving methods where downstream compatibility demands it — before that data is ever delivered. Book a demo to see it run against your own schema.

Sources: NIST CSRC — SP 800-38G Rev. 1 (2nd Public Draft), NIST SP 800-38G (original, PDF), NIST CSRC — NIST Released Special Publication 800-38G, Wikipedia — Format-preserving encryption, LinkedIn — Wias Issa on SP 800-38G Rev. 1, Tonic.ai — Real-World Applications of Format-Preserving Encryption, ALTR — FPE vs Tokenization vs TSS, DataStealth — Format-Preserving Encryption vs Tokenization, DataStealth — PCI DSS v4.0 Tokenization Requirements, FakeName Generator — Data Masking vs Synthetic Data vs Tokenization, ComplyGuide — PCI DSS Encryption Requirements Explained, Prime Factors — Complying with PCI DSS 4.0, Accutive Security — Guide to PCI DSS 4.0 Compliance: Data Masking & Tokenization, Prime Factors — Recognized in Gartner Hype Cycle for Privacy 2024, Prime Factors via PRWeb — Gartner Hype Cycle for Privacy 2024, Prime Factors via Cision PR Newswire — Gartner Hype Cycle for Digital Sovereignty 2025, Datasparc — Data Masking Techniques: A 2026 Enterprise Guide, comforte — The Difference between Format-Preserving Encryption and Tokenization, PCI Proxy — Encryption vs. Tokenization in PCI DSS v4, Network Intelligence — PCI DSS v4.0.1 Guidance Document, C² Data Technology.