EFS File System Not Encrypted: Why It Matters and How to Fix It

Amazon Elastic File System (EFS) gives you a shared, NFS-mountable file system that can be attached to dozens of EC2 instances, containers, and Lambda functions at once. Because it is so easy to mount and share, EFS often ends up holding exactly the kind of data you do not want sitting around in plaintext: application config, user uploads, log archives, build artifacts, and sometimes credentials that someone left in a file "temporarily."

The efs_unencrypted check looks for any EFS file system where encryption at rest is turned off. It is a quick read of a single property, but the consequences of getting it wrong stretch across compliance, incident response, and the basic question of who can read your data if they get their hands on the storage layer.

---

What this check detects

The check inspects every EFS file system in your AWS account and reports any where the Encrypted attribute is false. When EFS encryption at rest is enabled, both the data stored on disk and the metadata are encrypted using a key managed through AWS KMS. When it is disabled, the data is written to the underlying storage media in plaintext.

You can confirm the encryption status of a file system directly:

aws efs describe-file-systems \
  --query "FileSystems[*].{ID:FileSystemId,Encrypted:Encrypted,KmsKey:KmsKeyId}" \
  --output table

An unencrypted file system shows Encrypted: false and no KmsKeyId. That is the condition this check fails on.

---

Why it matters

Encryption at rest protects the data once it lands on physical media. Without it, you are relying entirely on access controls and the assumption that nobody will ever reach the storage layer through a path you did not anticipate. That assumption tends to fail in a few predictable ways.

Backups and snapshots inherit the problem

EFS is commonly backed up with AWS Backup. If the source file system is unencrypted, your recovery points carry the same exposure. A leaked or over-shared backup vault then becomes a plaintext copy of everything you stored.

Compliance frameworks treat it as a hard requirement

Encryption at rest is an explicit control in PCI DSS, HIPAA, SOC 2, FedRAMP, and most internal security baselines. An unencrypted file system holding regulated data is not a gray area, it is a finding. Auditors will ask for it, and "we forgot to enable it at creation" is an expensive answer when remediation means data migration.

Defense in depth against insider and supply-chain risk

Encryption at rest with a customer-managed KMS key means access to the data also requires permission to use the key. That gives you a second control point. You can revoke or audit key usage independently from file system access, which is valuable when responding to a compromised IAM role or a rogue insider.

---

How to fix it

Because encryption cannot be enabled in place, remediation is a migration: create a new encrypted file system, copy the data across, repoint your clients, then retire the old one. Plan for a maintenance window if the file system is in active use.

Step 1: Create a new encrypted file system

Using the default AWS-managed EFS key:

aws efs create-file-system \
  --encrypted \
  --performance-mode generalPurpose \
  --throughput-mode bursting \
  --tags Key=Name,Value=app-data-encrypted

For tighter control and independent key management, specify a customer-managed KMS key:

aws efs create-file-system \
  --encrypted \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd1234-... \
  --tags Key=Name,Value=app-data-encrypted

Step 2: Create mount targets

Add a mount target in each subnet where clients live, reusing the security group that allows NFS (TCP 2049):

aws efs create-mount-target \
  --file-system-id fs-0newencrypted0 \
  --subnet-id subnet-0abc123 \
  --security-groups sg-0nfsaccess0

Step 3: Copy the data

Mount both file systems on a temporary instance and copy with a tool that preserves permissions and ownership. rsync with archive mode works well:

sudo mkdir -p /mnt/old /mnt/new
sudo mount -t nfs4 -o nfsvers=4.1 fs-0old.efs.us-east-1.amazonaws.com:/ /mnt/old
sudo mount -t nfs4 -o nfsvers=4.1 fs-0new.efs.us-east-1.amazonaws.com:/ /mnt/new

sudo rsync -aHAX --info=progress2 /mnt/old/ /mnt/new/

Step 4: Repoint clients and verify

Update mount configurations, ECS task definitions, or Lambda file system configs to reference the new file system ID, then redeploy. Confirm checksums or a sample of files match before you decommission anything.

Step 5: Retire the old file system

# Remove mount targets first
aws efs delete-mount-target --mount-target-id fsmt-0old123

# Then delete the file system
aws efs delete-file-system --file-system-id fs-0oldunencrypted0

---

How to prevent it from happening again

Since the property is fixed at creation, prevention is about making sure no new unencrypted file system ever gets created. The most reliable place to enforce this is in your infrastructure code and in the account guardrails.

Encrypt by default in Terraform

Set encryption explicitly in every aws_efs_file_system resource and reference a KMS key:

resource "aws_efs_file_system" "app_data" {
  creation_token = "app-data"
  encrypted      = true
  kms_key_id     = aws_kms_key.efs.arn

  tags = {
    Name = "app-data"
  }
}

Block unencrypted file systems with an SCP

A Service Control Policy at the organization level can deny creation of any EFS file system that does not request encryption. This stops the problem regardless of who runs the API call or which tool they use:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedEFS",
      "Effect": "Deny",
      "Action": "elasticfilesystem:CreateFileSystem",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "elasticfilesystem:Encrypted": "false"
        }
      }
    }
  ]
}

Gate it in CI/CD

Catch the misconfiguration before it reaches AWS by scanning Terraform plans in your pipeline. Tools like tfsec or checkov flag unencrypted EFS resources out of the box:

checkov -d ./infra --check CKV_AWS_42

---

Best practices

• Use customer-managed KMS keys for sensitive data. They give you control over key rotation, independent access policies, and CloudTrail visibility into every decrypt operation.
• Pair encryption at rest with encryption in transit. Mount with the -o tls option using the EFS mount helper, or set transit_encryption = "ENABLED" in ECS volume configurations.
• Enforce encryption on backups too. Configure AWS Backup vaults with their own KMS key so recovery points are protected even if the source ever was not.
• Restrict access with file system policies and security groups. Encryption is a backstop, not a substitute for least-privilege NFS access.
• Audit continuously. Run the efs_unencrypted check on a schedule so a new file system created outside your pipeline is caught within hours, not at the next audit.

The cost of getting this right is essentially zero. EFS encryption at rest adds no charge and has negligible performance impact. The cost of getting it wrong is a data migration under audit pressure, or worse, an incident report explaining why customer data was sitting in plaintext. Set it at creation, enforce it with policy, and move on.