Skip to content
Ask AI about this
Help improve this page

EFS file systems should have encryption at rest enabled

EFS file systems often store application data, configuration files, and shared state that may include credentials or personally identifiable information. Without encryption at rest, anyone with physical access to the underlying storage media or unauthorized access to EFS API snapshots can read that data in plaintext.

Encryption at rest is a one-way door for EFS. You cannot enable it after the file system exists. Discovering an unencrypted file system in production means provisioning a new encrypted one, migrating all data with AWS DataSync or rsync, updating every mount target and consumer, and then deleting the original. Catching this at Terraform plan time avoids that entire remediation.

Retrofit consideration

EFS encryption at rest cannot be toggled after creation. Remediation requires creating a new encrypted file system, migrating all data, updating mount targets, and destroying the old file system. This causes downtime for dependent workloads.

Implementation

Choose the approach that matches how you manage Terraform.

Use the compliance.tf module to enforce this control by default. See get started with compliance.tf.

module "efs" {
  source  = "soc2.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "pcidss.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "hipaa.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "gdpr.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "nist80053.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "nistcsf.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "fedrampmoderate.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "cis.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "nist800171.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "nydfs23.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "cisv500.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "ffiec.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "eugmpannex11.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "cfrpart11.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "rbicybersecurity.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "hipaasecurity2003.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "nistcsfv11.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "nist80053rev4.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}


module "efs" {
  source  = "pcidssv321.compliance.tf/terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"
}

If you use terraform-aws-modules/efs/aws, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "efs" {
  source  = "terraform-aws-modules/efs/aws"
  version = ">=2.0.0"

  name = "abc123"

  encrypted = true
}

Use AWS provider resources directly. See docs for the resources involved: aws_efs_file_system.

resource "aws_efs_file_system" "this" {
  encrypted = true
}

What this control checks

This control validates that aws_efs_file_system has encrypted set to true. When encrypted is omitted or set to false, it fails. kms_key_id can optionally specify a customer-managed KMS key ARN; when omitted, EFS uses the AWS-managed key aws/elasticfilesystem. Both configurations pass as long as encrypted = true. Because encryption cannot be changed post-creation, this is effectively a plan-time gate: a file system deployed without encryption must be replaced entirely.

Common pitfalls

  • Encryption cannot be enabled after creation

    Add encrypted = true to an existing aws_efs_file_system and Terraform plans a replacement, which deletes all data on the current file system. This isn't a soft update, it's a destroy-and-recreate. Gate this in CI before first apply so the problem never reaches production.

  • Default is encrypted

    EFS defaults encrypted to true for new file systems, but don't rely on the default. If the argument is absent from your Terraform config, nothing stops someone from adding encrypted = false later without realizing the implication. Set it explicitly so the intent is visible and policy enforcement has something concrete to check.

  • KMS key policy may block access

    Get the KMS key policy right before deploying. When kms_key_id points to a customer-managed key, that key's policy must grant kms:GenerateDataKey* and kms:Decrypt to the EFS service principal. A restrictive policy silently causes mount failures even though the file system shows as encrypted.

  • Replication destinations inherit encryption settings separately

    Replication destinations are independent file systems. Setting encrypted = true on the source doesn't carry over to the destination created by aws_efs_replication_configuration. Specify the destination region's KMS key explicitly, or the replica may be unencrypted and will fail this control.

Audit evidence

Config rule efs-encrypted-check evaluation results showing all file systems as COMPLIANT are the primary artifact. Console screenshots of the EFS details page ("Encrypted: Yes" plus the KMS key ID) work as supplemental evidence. For programmatic proof, aws efs describe-file-systems output filtered to show "Encrypted": true on every file system covers the requirement.

CloudTrail CreateFileSystem entries should show Encrypted: true and a KmsKeyId in the request parameters, confirming the setting was applied at provisioning time rather than retroactively.

Framework-specific interpretation

SOC 2: CC6.1 and CC6.7 both factor in here. Encryption at rest limits data access to processes holding valid KMS permissions, which maps directly to the confidentiality and logical access criteria auditors check under SOC 2.

PCI DSS v4.0: Requirement 3.5 mandates that stored PANs are rendered unreadable. If cardholder data lands on a shared file system, EFS encryption at rest with KMS is what keeps it out of the clear, meeting the cryptographic protection expectations.

HIPAA Omnibus Rule 2013: 45 CFR 164.312(a)(2)(iv) is an addressable implementation specification requiring encryption of ePHI at rest. For any EFS file system carrying health data, enabling encryption satisfies this specification and ensures the data is unreadable without the KMS key.

GDPR: Article 32 calls for appropriate technical measures to protect personal data. Beyond the baseline protection, there's a practical benefit: under Article 34(3)(a), encrypted data may qualify for the exemption from individual breach notification obligations, which is a meaningful risk reduction for controllers.

NIST SP 800-53 Rev 5: SC-28 calls for cryptographic mechanisms to protect data at rest from unauthorized disclosure and modification. KMS-encrypted EFS meets this directly for anything stored on shared file systems.

NIST Cybersecurity Framework v2.0: PR.DS covers data-at-rest protection under the Protect function. Encrypted EFS volumes keep stored data confidential even if the underlying physical storage is accessed outside normal channels.

FedRAMP Moderate Baseline Rev 4: At the Moderate baseline, SC-28 requires FIPS-validated cryptographic modules for federal data at rest. AWS KMS satisfies the FIPS 140-2 requirement, so an encrypted EFS file system checks this box.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: efs_file_system_encrypt_data_at_rest

  • AWS Config Managed Rules: EFS_ENCRYPTED_CHECK, EFS_FILESYSTEM_CT_ENCRYPTED

  • Checkov Check: CKV_AWS_42

  • Powerpipe Control: aws_compliance.control.efs_file_system_encrypt_data_at_rest

  • Prowler Check: efs_encryption_at_rest_enabled

  • AWS Security Hub Controls: EFS.1, EFS.8

  • KICS Queries: 25d251f3-f348-4f95-845c-1090e41a615c, 48207659-729f-4b5c-9402-f884257d794f

  • Trivy Check: AWS-0037

Last reviewed: 2026-03-09