Format Preserving Encryption with NIST Recommendations

Format Preserving Encryption (FPE) is an encryption technique standardized by NIST in SP 800-38G that produces ciphertext with the same format and length as the plaintext. It matters because most legacy databases and applications cannot store AES ciphertext without schema changes, making standard encryption disruptive or impossible to deploy. The recommended action is to implement FPE using the FF1 algorithm with a FIPS 140-2 validated cryptographic module, manage the FPE key in a dedicated key management system separate from the encrypted data, and audit every encrypt and decrypt operation against an authenticated identity.

Quick Answer: When Should You Use Format Preserving Encryption?

Use FPE when a system has a fixed-length or fixed-format field that cannot be changed to accommodate expanded ciphertext, and where the encrypted value must remain usable as a reference key across multiple systems. Common use cases are protecting credit card numbers (Primary Account Numbers, or PANs) under PCI DSS, Social Security Numbers under HIPAA, account identifiers in legacy banking systems, and any structured data field where schema migration is not feasible. Do not use FPE as a substitute for general-purpose authenticated encryption (AES-GCM): FPE does not provide authentication (it cannot detect tampering), has lower security margins than AES-GCM for the same key length, and requires careful key and tweak management to avoid cryptographic weaknesses in FF3-1.

Key Takeaways

• FPE produces ciphertext with the same format and length as plaintext: A 16-digit credit card number encrypts to a 16-digit ciphertext. A 9-digit SSN encrypts to a 9-digit ciphertext. This allows encrypted data to pass through systems expecting the original data type without schema changes or application modifications.
• NIST SP 800-38G specifies two approved FPE algorithms, FF1 and FF3-1: Both are Feistel-network constructions built on AES. FF1 is the recommended algorithm for new implementations. FF3-1 superseded FF3 in the 2024 revision after security weaknesses in FF3 were identified; FF3 (the original) is no longer recommended.
• FPE does not provide authenticated encryption: Unlike AES-GCM, FPE has no built-in message authentication code (MAC). An attacker who can modify the ciphertext in place will produce different valid ciphertext without detection. FPE must be used alongside integrity controls at the application or database layer.
• Key rotation for FPE requires re-encrypting every protected field value: Because the ciphertext must match the original field format, re-keying requires decrypting all values with the old key and re-encrypting them with the new key. This is a planned database maintenance operation, not a transparent background rotation.
• FPE satisfies PCI DSS, HIPAA, and GDPR requirements when properly implemented: FPE with a NIST SP 800-38G compliant algorithm using a FIPS 140-2 validated module meets the encryption requirements of PCI DSS v4.0.1 (Requirement 3.5.1 for PAN protection), HIPAA Technical Safeguards (164.312(a)(2)(iv)), and GDPR pseudonymization requirements (Article 89).

What Is Format Preserving Encryption?

Format Preserving Encryption (FPE) is an encryption algorithm that transforms plaintext into ciphertext with exactly the same format and length as the original data. Standard encryption algorithms such as AES in CBC or GCM mode produce ciphertext that is longer than the plaintext and contains characters outside the original alphabet. FPE, by contrast, encrypts a 16-digit decimal number into a 16-digit decimal number, a 9-character alphanumeric code into a 9-character alphanumeric code, and so on, using whatever finite symbol alphabet the plaintext uses.

This property matters because most production databases and applications define fields with strict data types and fixed lengths. A credit card field defined as a 16-character numeric column cannot store the base64-encoded output of AES-128 encryption (0B6X8rMr058Ow+z3Ju5wimxYERpomz402++zNozLhvw= is 44 characters, not 16, and contains non-numeric characters). Storing AES ciphertext in such a field would require a schema migration across the database, changes to every application reading or writing that column, and updates to every downstream system expecting the original format. For legacy systems, such migrations are often technically impractical or prohibitively expensive. FPE eliminates that requirement: the encrypted value fits the existing field without any schema or application change.

NIST SP 800-38G: The Standard Governing FPE

NIST SP 800-38G, Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption, is the authoritative NIST standard for FPE. Originally published in March 2016 and revised in 2024, it specifies two approved FPE algorithms: FF1 and FF3-1. Both are built on AES as the underlying block cipher, which means they inherit AES’s FIPS 140-2 compliance status when implemented within a FIPS 140-2 validated cryptographic module.

The standard defines FPE formally: given a finite alphabet of symbols (such as the decimal digits 0 through 9, or the alphanumeric characters), an FPE algorithm transforms a sequence of symbols from that alphabet into another sequence of the same length using the same alphabet, under a secret key. The definition requires a minimum alphabet of two symbols and a minimum plaintext length of two symbols. The encrypted output is indistinguishable from a random permutation of the plaintext space under the given key and tweak, providing security against an attacker who does not know the key.

The standard also specifies that FPE keys must be AES keys: 128-bit, 192-bit, or 256-bit. For most regulated deployments, 256-bit keys are recommended for alignment with FIPS 140-2 Level 3 requirements and for forward compatibility with post-quantum migration planning. The standard does not specify key management procedures; those are governed by NIST SP 800-57 (Recommendation for Key Management).

FF1 and FF3-1: The Two NIST-Approved FPE Algorithms

NIST SP 800-38G specifies two FPE algorithms, each suited to different implementation scenarios.

FF1 (Format Preserving Feistel-based Encryption Mode 1)

FF1 is the recommended FPE algorithm for new implementations. It is a Feistel network construction using AES as the round function, with a variable-length tweak. The tweak is an additional input (similar to an initialization vector) that allows the same key to produce different ciphertext outputs for the same plaintext value when the tweak differs. The tweak can be any byte string of arbitrary length, which gives FF1 the flexibility to incorporate contextual data such as a record identifier, a table name, or a transaction date as part of the encryption input without changing the key.

FF1 is appropriate for most FPE use cases: encrypting PANs, SSNs, account numbers, phone numbers, and other structured data fields. It supports any alphabet size from 2 to 2^32 symbols and any plaintext length from 2 to 2^32 symbols (subject to the constraint that the alphabet size raised to the length must be at least 100). FF1 is computationally slightly slower than FF3-1 due to more Feistel rounds, but the performance difference is negligible for most enterprise workloads.

FF3-1 (Format Preserving Feistel-based Encryption Mode 3, Revision 1)

FF3-1 is the revised version of FF3, updated in the 2024 revision of NIST SP 800-38G after security researchers identified a weakness in the original FF3 specification. The weakness allows an attacker who can observe a large number of ciphertext values encrypted with the same key and tweak to recover information about the key. The 2024 revision addresses this by requiring the tweak to be exactly 7 bytes (56 bits) and by tightening the constraints on how many encryptions may be performed with the same key-tweak pair.

FF3-1’s fixed 7-byte tweak is more constrained than FF1’s variable-length tweak, making FF3-1 less flexible for use cases requiring contextual tweaks. The practical implication is that applications using FF3-1 must manage tweak diversity carefully to avoid the known attack. For new implementations, NIST recommends FF1 unless there is a specific reason to use FF3-1. Organizations currently using FF3 (the original, pre-2024 version) should migrate to FF1 or FF3-1.

Property	FF1	FF3-1
Standardized in	NIST SP 800-38G (2016, revised 2024)	NIST SP 800-38G (2016, revised 2024)
Underlying block cipher	AES (128, 192, or 256-bit key)	AES (128, 192, or 256-bit key)
Tweak length	Variable (any byte string)	Fixed 7 bytes (56 bits)
Feistel rounds	10	8
Alphabet support	2 to 2^32 symbols	2 to 2^32 symbols
Known weaknesses	None identified in current specification	Original FF3 had key-recovery weakness; FF3-1 addresses it with tweak constraints
NIST recommendation for new use	Preferred	Acceptable with strict tweak management
Best for	Most FPE use cases; flexible tweak applications	Legacy systems already using FF3; tokenization with short fixed tweaks

Format Preserving Encryption Use Cases

FPE is most valuable in use cases where data format and length must be preserved through the encryption process. The following are the primary enterprise use cases:

Payment card data protection (PCI DSS PAN encryption): Primary Account Numbers (PANs) are 16-digit numbers that flow through payment processing systems with strict format expectations. FPE allows PANs to be encrypted at the point of entry and to flow as encrypted 16-digit values through all downstream systems, including legacy payment processors, fraud detection engines, and reporting databases, without any system modification. PCI DSS v4.0.1 Requirement 3.5.1 explicitly recognizes FPE as an acceptable method for protecting stored PANs.

Healthcare patient identifier protection (HIPAA): Social Security Numbers (9-digit), patient account numbers, and other structured identifiers used in healthcare databases are natural candidates for FPE. Encrypting a 9-digit SSN with FPE returns a 9-digit encrypted value that continues to serve as a lookup key across linked databases without exposing the underlying PII. This satisfies HIPAA’s requirement to protect electronic Protected Health Information (ePHI) at rest under 45 CFR 164.312(a)(2)(iv).

Legacy database encryption without schema migration: Organizations with older databases defined using fixed-length character or numeric columns can apply FPE to encrypt sensitive fields without any schema change, data migration, or application modification. The encrypted value is the same type and length as the original, so all existing queries, indexes, stored procedures, and applications continue to function. Encryption can be applied at the application layer or, in some database systems, at the column level through user-defined functions.

Data de-identification for analytics and testing: Organizations that need to share production data extracts with analytics teams, development environments, or auditors can use FPE to de-identify sensitive fields. The encrypted values maintain referential integrity (the same plaintext always encrypts to the same ciphertext under the same key and tweak), so joins and aggregations across tables continue to work correctly on the de-identified data, while the underlying PII is protected. FPE is particularly useful for GDPR pseudonymization under Article 89 when the FPE key is stored separately from the pseudonymized dataset.

Cloud migration of sensitive data: When migrating sensitive data from on-premises databases to cloud storage, FPE allows data to be encrypted before upload without requiring changes to the schema or the cloud database configuration. The encrypted values in the cloud database remain the same type and length as the originals, preserving compatibility with all application queries, while the actual sensitive values are protected by FPE encryption with a key held on-premises or in a BYOK configuration.

FPE Key Management: Native, BYOK, and HYOK

The security of an FPE implementation depends entirely on the protection of the FPE key. A compromised FPE key allows an attacker to decrypt all protected field values across the entire database. Key management for FPE follows the same three-model framework as other encryption use cases.

Native Key Management (Provider-Managed)

In a native key management model, the cloud provider or FPE service generates and manages the AES key used for FPE operations. Your application calls the FPE service API with the plaintext value and receives the encrypted value; the key itself is managed by the service. The advantage is minimal operational overhead. The disadvantage is that the service provider has operational access to the key and, by extension, the ability to decrypt all FPE-protected values. For most general compliance workloads, this model is acceptable when the provider is within your compliance boundary and the service is covered by appropriate contractual controls (BAA for HIPAA, DPA for GDPR). For regulated data requiring customer key provenance, native key management is insufficient.

BYOK (Bring Your Own Key) for FPE

BYOK for FPE means generating the AES FPE key in your own hardware security module (HSM) or key management system and importing it into the FPE service or cloud KMS. The FPE key material is generated under your control, with your organization able to independently verify its provenance. The cloud service uses your imported key material to perform FPE operations, but you retain the original key in your HSM and can revoke it by deleting the imported copy from the service. BYOK satisfies regulatory requirements that mandate customer-generated key material for encryption of regulated data (some PCI DSS QSA interpretations of Requirement 3.7.1, certain FedRAMP controls). For FPE specifically, BYOK implementations typically use an on-premises HSM or a third-party HSM as a Service as the key generation source, with the key imported into the cloud FPE service.

HYOK (Hold Your Own Key) for FPE

HYOK for FPE means the FPE key never enters the cloud service at all. FPE encryption and decryption are performed in your own infrastructure (an on-premises application layer or a client-side library), and only the FPE-encrypted values are uploaded to cloud storage or databases. The cloud provider stores only ciphertext and cannot decrypt any protected field, even in response to a legal demand. HYOK provides the strongest data sovereignty for FPE use cases. The operational cost is that every FPE encrypt and decrypt operation must make a round-trip to your on-premises key management system, which must be highly available for your application to function. This architecture is appropriate for classified data, sovereignty-mandated environments, or organizations where the cloud provider itself is within the threat model.

Dimension	Native Key Management	BYOK (Customer-Generated Key in Service)	HYOK (FPE Performed Outside Cloud)
FPE key generated by	Cloud provider or FPE service	Customer HSM (imported into service)	Customer (never enters cloud)
Provider access to FPE key	Yes	Yes (operational access)	No
Provider can decrypt FPE fields	Yes	Yes (during operation)	No
Independent key revocation	Via service API only	Delete imported key (immediate)	Revoke at on-premises KMS
Operational complexity	Low	Medium	High
PCI DSS key provenance requirement	Depends on QSA interpretation	Satisfies customer key material requirements	Fully satisfies
Best for	General compliance workloads with provider controls	Regulated sectors requiring independent key provenance	Classified, sovereignty-mandated, zero-trust environments

IAM Model for FPE Access Control

Access control for FPE operations requires the same three-role separation that applies to any key management system. Misconfiguring IAM for FPE is particularly consequential because FPE keys protect structured data fields that may span millions of records across multiple databases.

Key administrator role: Creates, imports, and manages the FPE key lifecycle. Authorizes key creation, rotation events, and deletion. Must not be the same identity as the application service account that performs FPE operations. Key administrator actions (key creation, deletion scheduling, policy changes) must be logged and subject to dual control for high-value operations such as key generation ceremonies and deletion of keys protecting production data.

FPE operator role (crypto officer): Performs the FPE encrypt and decrypt API calls on behalf of the application. Has permission to use the FPE key for encrypt and decrypt operations but not to create, delete, or export the key. In cloud KMS terms, this maps to granting the application service account only the specific encryption and decryption permissions on the specific FPE key, not broad KMS access. For AWS deployments, this is the kms:Encrypt and kms:Decrypt permission on the specific key ARN only. Service control policies (SCPs) in an AWS Organization can enforce that no application role obtains key management permissions.

Data consumer role (read-only access to encrypted fields): Applications or users that read database fields containing FPE-encrypted values but do not need to decrypt them (for example, a reporting system that treats the encrypted value as an opaque identifier for joining purposes) should not have FPE decrypt permissions at all. Only the specific application service account that requires readable plaintext should have decrypt access to the FPE key.

Key Rotation for FPE: Special Considerations

Key rotation for FPE is fundamentally different from key rotation for standard encryption. In standard envelope encryption (as used by AWS KMS, Azure Key Vault, and GCP Cloud KMS), rotating the master key means generating new key material for the master key and using it to re-wrap the data encryption keys. The actual data does not need to be re-encrypted. With FPE, there is no envelope encryption layer: the FPE key encrypts the field values directly. Rotating the FPE key therefore requires decrypting every protected field value with the old key and re-encrypting it with the new key, across every table and column that uses that FPE key.

This has several operational implications. First, FPE key rotation cannot happen transparently in the background; it requires a planned maintenance window or a read-shadow architecture during the rotation period (where the old and new keys are both active, new writes use the new key, and reads fall back to the old key if the new key does not decrypt successfully). Second, FPE key rotation frequency is typically lower than for standard KMS keys: most organizations rotate FPE keys annually or on a defined schedule aligned with PCI DSS Requirement 3.7.4 (which requires periodic cryptoperiods for symmetric keys). Third, the key rotation procedure must be tested and rehearsed before execution on production data, because a failed FPE rotation that leaves data in an inconsistent key state can render entire database columns inaccessible.

Best practices for FPE key rotation: maintain a key version identifier alongside each FPE-encrypted field (a single column or flag indicating which key version encrypted the value); design the application to accept both old and new key versions during the rotation period; rotate in batches to limit the scope of any failure; verify decryption with the new key for each batch before deleting old values; and retain the old key in an archived but inaccessible state until all data has been verified as rotated.

Audit Logging for FPE Operations

Every FPE encrypt and decrypt operation should be logged with the requesting identity, the timestamp, the key identifier used, and the field type (without the plaintext or ciphertext value). Audit logs for FPE serve compliance evidence requirements under PCI DSS Requirement 10 (logging and monitoring) and HIPAA’s Audit Control standard (45 CFR 164.312(b)).

For cloud-based FPE implementations that use a cloud KMS as the key store, every FPE operation that calls the KMS to wrap or unwrap a data key generates a CloudTrail event (in AWS), an Azure Monitor event (in Azure), or a Cloud Audit Log event (in GCP). These per-operation audit trails are one reason regulated organizations prefer cloud KMS-backed FPE over application-layer key storage: the audit trail is automatically generated, tamper-evident, and does not require custom logging infrastructure.

Alert on the following FPE-related audit events: bulk decrypt operations against FPE-protected columns by any identity not in the approved application role list (a possible data extraction attempt); FPE key deletion or scheduling for deletion outside a documented rotation event; any change to the FPE key policy or access controls; and FPE operations originating from IP addresses or IAM identities not associated with known application deployments.

Cloud FPE Implementations

FPE functionality is available through multiple cloud provider services and can also be implemented using open-source libraries with a cloud KMS as the key store. The implementation approach depends on whether the cloud service provides native FPE support or whether FPE must be implemented at the application layer.

Google Cloud: Cloud DLP with FPE De-identification

Google Cloud provides native FPE functionality through Cloud Data Loss Prevention (Cloud DLP), now called Sensitive Data Protection. The DLP API allows customers to call FPE encryption and decryption on structured data fields, with the FPE key managed in Cloud KMS. The DLP API supports FF1 encryption over the decimal digit alphabet (for numeric fields such as credit card numbers and SSNs) and over the alphanumeric alphabet (for mixed-character identifiers). The key used for FPE can be a wrapped key stored alongside the request (BYOK, where the wrapping is done by the caller’s Cloud KMS key) or a Cloud KMS-managed key. Cloud DLP FPE satisfies PCI DSS requirements for PAN protection and HIPAA requirements for ePHI de-identification when configured with appropriate key access controls.

AWS: Application-Layer FPE with AWS KMS Key Backing

AWS does not offer a native FPE API service. AWS implementations of FPE use an FPE library at the application layer (such as the open-source FF1 or FF3-1 implementations available for Java, Python, and Go) with the FPE key stored in and retrieved from AWS KMS. The application retrieves the AES key from KMS at startup or on demand, performs FPE operations locally using the retrieved key, and writes only the FPE-encrypted values to the database. The FPE key stored in AWS KMS can be a customer-managed key with BYOK (imported key material with Origin: EXTERNAL) or a KMS-generated key. All key access operations generate CloudTrail events providing the audit trail for key usage. This approach gives organizations full control over the FPE algorithm implementation while leveraging AWS KMS for key protection and audit logging.

Azure: Application-Layer FPE with Azure Key Vault Key Backing

Azure similarly does not provide a native FPE API service. Azure FPE implementations use application-layer FPE libraries with the AES key stored in Azure Key Vault (standard or HSM-protected tier). Azure Key Vault supports customer-managed keys, BYOK (key import from your own HSM), and HSM-protected key storage in Azure Dedicated HSM for FIPS 140-2 Level 3 validation. All Key Vault operations generate Azure Monitor audit logs. Azure Purview (now Microsoft Purview) provides data classification capabilities that can identify sensitive fields requiring FPE protection, making it a useful discovery tool before FPE implementation.

FPE vs. Tokenization: Choosing the Right Approach

FPE and tokenization are often used for the same purpose (protecting structured data fields without changing their format) but work differently and have different security properties.

Tokenization replaces a sensitive value with a randomly generated surrogate value (a token) of the same format, stored in a token vault that maps tokens back to original values. The token has no mathematical relationship to the original value; recovering the original requires a lookup in the token vault. Tokenization provides strong security because even with the token vault compromised in isolation, the token reveals nothing about the original value without the complete mapping table. However, tokenization requires a centralized token vault that must be highly available, can become a bottleneck, and must be protected as a primary target for attackers.

FPE is deterministic and vaultless: the same plaintext value encrypted with the same key and tweak always produces the same ciphertext, with no lookup required. This makes FPE stateless and highly scalable, but it also means FPE ciphertext can be subjected to frequency analysis if the plaintext space is small (for example, a single-digit field with values 0 through 9 produces only 10 possible ciphertexts, making frequency analysis trivial). FPE is appropriate for fields with large plaintext spaces (16-digit credit card numbers have 10^16 possible values; frequency analysis is not practical). For small plaintext spaces, tokenization is the more appropriate choice.

Compliance Coverage: PCI DSS, HIPAA, and GDPR

PCI DSS v4.0.1 (mandatory since March 31, 2025): Requirement 3.5.1 requires that primary account numbers (PANs) stored in any environment in scope for PCI DSS be rendered unreadable using strong cryptography. FPE using FF1 or FF3-1 with a 256-bit AES key and proper key management satisfies this requirement. The PCI DSS glossary explicitly lists format-preserving encryption as an acceptable rendering method. Requirements 3.7.1 through 3.7.9 govern key management for the FPE key, including key generation procedures, key custodian roles, key rotation schedules, and key destruction procedures. Requirement 10 governs audit logging for all access to cardholder data, including FPE encrypt and decrypt operations.

HIPAA Technical Safeguards: The Encryption and Decryption standard (45 CFR 164.312(a)(2)(iv)) requires that ePHI at rest be encrypted using a mechanism to protect it from unauthorized access. FPE with NIST SP 800-38G compliant algorithms satisfies this standard. NIST Special Publication 800-111 (Guide to Storage Encryption Technologies for End User Devices) and the HHS guidance on encryption and decryption both recognize AES-based encryption as meeting the HIPAA encryption standard; FPE built on AES inherits that compliance status. The Audit Control standard (45 CFR 164.312(b)) requires logging of access to ePHI, which is satisfied by the per-operation audit logs generated by the FPE key management system.

GDPR pseudonymization (Articles 25 and 89): GDPR Article 89 allows reduced requirements for data subject rights (right to erasure, right to access) for pseudonymized data used for research or statistical purposes. FPE satisfies GDPR’s definition of pseudonymization (Article 4(5): processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information) when the FPE key is stored separately from the pseudonymized data and protected with appropriate access controls. FPE-pseudonymized data sets can be shared with analytics teams or research partners with reduced compliance burden when the FPE key is not included in the shared data.

FPE Limitations and What to Watch Out For

FPE has important limitations that must be understood before deployment.

No authentication: FPE does not provide authenticated encryption. An attacker who can modify FPE-encrypted values in the database will produce different valid encrypted values without detection. Database-level integrity controls (hash-based checksums, application-layer MACs, or database triggers) are needed to detect unauthorized modification of FPE-protected fields.

Determinism enables frequency analysis for small plaintext spaces: Because the same plaintext always encrypts to the same ciphertext under the same key and tweak, FPE-encrypted fields can be subjected to frequency analysis when the plaintext space is small. A field containing only the values 0 through 9 produces only 10 distinct ciphertexts; an attacker who knows the distribution of the original values can often re-identify them from the distribution of the encrypted values. Tweaks mitigate this by making the ciphertext depend on the tweak as well as the plaintext and key; use a per-record or per-transaction tweak whenever possible.

Key rotation requires full re-encryption: As described in the key rotation section, rotating an FPE key requires re-encrypting every value in every protected field. This is a significant operational burden for large databases and must be planned carefully.

FF3 (original, pre-2024) is no longer recommended: Organizations using FF3 (not FF3-1) implementations should migrate to FF1 or FF3-1. The original FF3 has a known key-recovery weakness when the same key and tweak combination is reused across many encryptions. Most commercial FPE libraries have been updated to FF3-1 or FF1, but verify your library version before assuming compliance with current NIST guidance.

How Encryption Consulting Can Help

Encryption Consulting is an applied cryptography firm with ISO/IEC 27001:2022 and SOC 2 certifications. We help organizations design, implement, and audit FPE deployments for PCI DSS, HIPAA, GDPR, and other compliance frameworks.

• FPE Architecture and Implementation: We design the FPE architecture for your environment, including algorithm selection (FF1 vs. FF3-1), tweak strategy, key management model (native, BYOK, or HYOK), IAM role structure, rotation procedure, and audit logging configuration. We implement and test the FPE integration for AWS KMS-backed, Azure Key Vault-backed, or Google Cloud DLP deployments. See our data protection services.
• HSM as a Service for FPE Key Generation: For BYOK FPE implementations requiring FIPS 140-2 Level 3 key generation, Encryption Consulting’s HSM as a Service provides dedicated HSM infrastructure as the key generation source. FPE keys are generated in the HSM, exported in wrapped form, and imported into your cloud KMS or FPE service. The HSM as a Service is accessible across AWS, Azure, and GCP environments.
• CBOM Secure for FPE Discovery: Before implementing FPE, organizations need to identify all fields across their database estate that contain sensitive structured data requiring FPE protection. Encryption Consulting’s CBOM Secure discovers and inventories all sensitive data fields, existing encryption implementations, and cryptographic gaps across cloud and on-premises environments, generating a Cryptographic Bill of Materials that prioritizes FPE implementation by risk and compliance urgency.
• PCI DSS and HIPAA Compliance Advisory: We map your FPE implementation to the specific requirements of PCI DSS v4.0.1 (Requirements 3.5.1, 3.7.1 through 3.7.9, and Requirement 10), HIPAA Technical Safeguards, and GDPR pseudonymization requirements. We identify gaps, produce the compliance evidence package, and assist with QSA and auditor inquiries. See our Compliance Advisory Services.
• PQC Readiness for FPE: FPE algorithms are built on AES, which is not directly threatened by quantum computing in the near term (AES-256 requires doubling the key search space for Grover’s algorithm, maintaining adequate security). However, the key management infrastructure protecting FPE keys (RSA-based key wrapping, ECDH for key exchange) may need to migrate to post-quantum algorithms before 2030. Encryption Consulting’s PQC Readiness service assesses your FPE key management infrastructure against NIST’s post-quantum migration timeline (NIST IR 8547, RSA/ECC deprecated ~2030).

To discuss your FPE implementation requirements, contact Encryption Consulting.

Conclusion

Format Preserving Encryption with NIST SP 800-38G recommendations provides a practical path to encrypting sensitive structured data in environments where schema changes are not feasible. The two NIST-approved algorithms, FF1 and FF3-1, are both built on AES and are FIPS 140-2 compliant when implemented with a validated cryptographic module. FF1 is the recommended algorithm for new implementations; FF3-1 is acceptable with strict tweak diversity management. FPE satisfies PCI DSS v4.0.1 PAN protection requirements, HIPAA ePHI encryption requirements, and GDPR pseudonymization requirements when paired with proper key management and audit logging.

The most important operational considerations for FPE are key separation from the data it protects, careful IAM role design to limit decrypt access to only the application identities that require it, and the operational complexity of key rotation requiring full re-encryption of all protected field values. Getting these right from design time, rather than retrofitting them into a deployed FPE implementation, is significantly easier and produces a more defensible compliance posture.

Frequently Asked Questions

What is Format Preserving Encryption (FPE)?

Format Preserving Encryption (FPE) is an encryption technique that produces ciphertext with the same format and length as the plaintext. Encrypting a 16-digit credit card number returns a 16-digit encrypted value; encrypting a 9-digit SSN returns a 9-digit encrypted value. NIST SP 800-38G standardizes two FPE algorithms: FF1 (recommended for new implementations) and FF3-1. Both are built on AES and are FIPS 140-2 compliant when implemented with a validated cryptographic module.

What is NIST SP 800-38G and what does it specify for FPE?

NIST SP 800-38G, Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption, is the authoritative NIST standard for FPE. First published in 2016 and revised in 2024, it specifies FF1 and FF3-1 as the two approved FPE algorithms. Both require AES keys (128-bit, 192-bit, or 256-bit). FF3-1 superseded the original FF3 after security weaknesses in FF3 were identified; organizations using FF3 should migrate to FF1 or FF3-1.

When should you use FPE instead of standard AES encryption?

Use FPE when the application or database has a fixed-length field that cannot accommodate expanded AES ciphertext, when the encrypted value must serve as a reference key across multiple systems expecting the original format, or when encrypting legacy system data without schema migration. Do not use FPE as a general-purpose authenticated encryption substitute: FPE provides no authentication (it cannot detect tampering) and has lower security margins than AES-GCM for equivalent key lengths.

What is the difference between FF1 and FF3-1?

Both FF1 and FF3-1 are Feistel-based FPE algorithms using AES. FF1 uses a variable-length tweak, making it more flexible for applications needing contextual input to the encryption. FF3-1 uses a fixed 7-byte tweak and was designed for tokenization use cases with short contextual values. FF3-1 revised the original FF3 after a key-recovery weakness was identified in FF3 when the same key-tweak pair is reused across many messages. For new implementations, NIST recommends FF1.

Does FPE meet HIPAA and PCI DSS compliance requirements?

Yes. FPE with NIST SP 800-38G compliant algorithms (FF1 or FF3-1) using FIPS 140-2 validated modules satisfies HIPAA Technical Safeguards (45 CFR 164.312(a)(2)(iv)) for ePHI at rest. PCI DSS v4.0.1 Requirement 3.5.1 explicitly recognizes format-preserving encryption as an acceptable method for protecting stored PANs. Under GDPR, FPE satisfies pseudonymization requirements (Article 89) when the FPE key is stored separately from the pseudonymized data.

How are FPE keys managed and rotated?

FPE keys are AES keys that must be stored separately from the data they protect, in a dedicated KMS or HSM. Key rotation for FPE requires decrypting every protected field value with the old key and re-encrypting it with the new key (unlike standard envelope encryption, where only the master key is rotated without touching the data). This is a planned database maintenance operation, not a transparent background rotation. BYOK implementations generate the FPE key in an HSM and import it into the cloud KMS; HYOK implementations keep the FPE key entirely outside the cloud provider.