AWS Transfer Family Security: Harden SFTP Users, Keys and Access

AWS Transfer Family puts SFTP, FTPS, FTP and AS2 endpoints in front of Amazon S3 and Amazon EFS, so a loose user mapping, a permissive role or a careless custom identity provider turns a partner file drop into direct access to your storage. The service removes the server patching burden of a self-hosted file transfer box, but the identity layer is yours: every user maps to an IAM role, every custom login is a Lambda function you wrote, and every endpoint decision sets who on the internet can try to log in. This guide covers user types and authentication, SSH keys, custom identity providers, session policies and logical directories, endpoint and security policy choices, AS2 trading partner security, logging and a hardening baseline. It is written for cloud, integration and security engineers who run partner or internal file exchange on AWS. Cross-product file transfer risk and selection are covered in the Managed File Transfer (MFT) Security Guide; this page stays on Transfer Family.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.

Key takeaways

• Every login becomes an IAM role session. When a user connects, Transfer Family assumes the role mapped to that user, so the role, not the SFTP account, decides what can be read, written or deleted in S3 or EFS.
• Confine users twice. Logical directories (HomeDirectoryType set to LOGICAL) give a chroot view and hide bucket names; a unique role or session policy enforces least privilege at the storage layer, which AWS still recommends alongside logical directories.
• A custom identity provider is authentication code you own. A user is authenticated if and only if the Lambda returns a non-blank Role; restrict who can invoke the function, never log the event (it carries the plaintext password) and use sourceIp and protocol to narrow logins.
• Name the security policy explicitly. The console default is TransferSecurityPolicy-2024-01, but CloudFormation's default is the much older TransferSecurityPolicy-2018-11; the 2025 policies add post-quantum key exchange and drop SHA-1 based algorithms.
• Prefer a VPC endpoint with security groups. EndpointType=VPC supports internal or internet-facing access, Elastic IPs and security group allow-lists for partner source ranges.

How identity and access work in Transfer Family

A Transfer Family server has one identity provider type, chosen at creation. Each user is then mapped to an IAM role (AWS calls it a service role) that Transfer Family assumes for the session, optionally narrowed by a session policy, with a home directory that is either a real path or a logical mapping.

For most custom cases AWS recommends its open source custom identity provider toolkit over writing a function from scratch. Usernames are 3 to 100 characters from a-z, A-Z, 0-9, underscore, hyphen, full stop and @, and cannot start with a hyphen, full stop or @.

SSH keys for service-managed users

• Key types: RSA (use rsa-sha2-256 or rsa-sha2-512), ECDSA (ecdsa-sha2-nistp256, -nistp384, -nistp521) and ssh-ed25519. RSA and ECDSA are FIPS compliant; Ed25519 is not. Legacy ssh-rsa with SHA-1 works only with older security policies.
• Keys are long-lived credentials held by a third party: record an owner and an expiry for every key, require partners to generate keys themselves (never email a private key), and add a new key before removing the old one so rotation does not break transfers.
• Self-service rotation: AWS publishes patterns for user self-service key management with Lambda and Terraform modules for users with multiple keys. See the SSH Key Management Guide.

Admin roles and privileged access

Administrators of Transfer Family can create users, attach roles and add keys, which is equivalent to granting storage access. Treat these API permissions as privileged.

• Session policies are stored by value: Transfer Family stores the policy JSON, not the ARN. Editing the IAM policy later does not change existing users; you must update each user with the new contents, so an emergency tightening needs a scripted update across users.
• Per-user roles versus shared roles: a unique role per partner is easiest to reason about and to revoke. A shared role with a session policy scales better, but only for S3.
• Separate accounts: host partner-facing servers in a dedicated account so the blast radius of an administrative mistake stays small. See the AWS IAM Policies and Roles Guide.

Integrations, API tokens and service accounts

Custom identity provider functions

Transfer Family calls your function with username, password, protocol (SFTP, FTPS or FTP), serverId and sourceIp. The response decides everything about the session.

• Branch on the password correctly: AWS samples treat an empty password as a key authentication request. A function that falls through to success when the password is blank, or returns PublicKeys during password authentication, breaks the model.
• Check context, not only presence: the AWS sample only checks that serverId is present. Production code should verify the exact server ID, restrict by sourceIp per partner and refuse protocols the user should not use.
• Restrict invocation: the function's resource-based policy should allow only transfer.amazonaws.com to call lambda:InvokeFunction, with an ArnLike condition on AWS:SourceArn set to your server ARN.
• Never log the full event: it contains the plaintext password. Log username, server ID, source IP and outcome only.
• Keep the identity store's own credentials in Secrets Manager: the function's execution role is a non-human identity with access to every user's credentials. See the AWS Lambda Security Guide.
• Same account and Region: AWS's best practice is to deploy the provider alongside the server, apply least privilege to its roles, use IP allow-listing and standardised logging, and test outside production first.

Session policies and logical directories

Session policies restrict a user to part of an S3 bucket and are evaluated in real time. They are S3 only (EFS uses POSIX permissions), have a maximum length of 2,048 characters, and support ${transfer:HomeBucket}, ${transfer:HomeDirectory}, ${transfer:HomeFolder} and ${transfer:UserName}. Three caveats catch teams out:

• Variables only in session policies: they cannot be used in managed policies or role definitions, and ${aws:Username} refers to an IAM user, not the Transfer username.
• Logical directories disable some variables: with HomeDirectoryType set to LOGICAL, HomeBucket, HomeDirectory and HomeFolder are not supported; use ${transfer:UserName} in targets instead.
• No nested substitution: a variable that expands to a value containing another variable is not resolved again. AWS advises testing every session policy, because it may not grant what you intended.

Logical directories map a virtual Entry to a real Target so users never see bucket or file system names. With Entry of / only one mapping is allowed. Transfer Family validates paths with relative elements and blocks any that would resolve outside the mapping. Limits are 2,000 entries for service-managed users and 2.1 MB of mappings for custom IdP and AD users.

AS2 trading partners

• Building blocks: a local profile, a partner profile, X.509 certificates (2,048 to 4,096 bit keys), an agreement for inbound messages and a connector for outbound ones. Self-signed certificates are supported for outbound only.
• Transport: inbound AS2 is HTTP only; terminate TLS on an Application or Network Load Balancer for HTTPS. Message encryption is required over HTTP; unencrypted messages are accepted only through a TLS-terminating proxy that sets X-Forwarded-Proto: https. Partner HTTPS endpoints must use a publicly trusted certificate and TLS 1.2.
• Algorithms: encryption AES128, AES192 or AES256 CBC, with 3DES for backward compatibility only; digests SHA1 to SHA512. Use AES256 and SHA256 or stronger, and TransferSecurityPolicy-AS2Restricted-2025-07 to exclude 3DES and SHA-1.
• Connector basic authentication: supported for outbound messages only; the credential lives in Secrets Manager, so scope access to that secret tightly.
• Not supported: mutual TLS, certificate exchange messaging and multiple attachments, so certificate rollover with partners is a manual, scheduled process. Track certificate expiry dates.

Logging and detection

AWS recommends JSON structured logging for servers, delivered to CloudWatch Logs (log groups under /aws/transfer/), which supports CloudWatch Logs Insights queries. Configuring it needs logs:CreateLogDelivery and related log delivery permissions; connectors and some workflows still use a logging role. Control-plane changes appear in AWS CloudTrail.

Metrics: percentage of users on logical directories; users mapped to roles with wildcard S3 resources (target zero); SSH keys older than the agreed maximum age; servers on a security policy older than 2024 (target zero); authentication failure rate per server; days to AS2 certificate expiry. Feed logs to your SIEM; see the AWS CloudTrail Guide.

Hardening baseline

Endpoint and network

• Ports: SFTP on 22 (2222 or 22000 can be added); FTP and FTPS control on 21 and data on 8192 to 8200. If no security group is chosen, the VPC default group is attached, so always set one explicitly.
• Protocols: enable SFTP or FTPS only. Plain FTP sends credentials in clear text and belongs only on internal endpoints, if at all.

Security policy and storage

• Security policy: set TransferSecurityPolicy-2025-03 (or TransferSecurityPolicy-FIPS-2025-03 where FIPS is required) explicitly; AWS says the default may change and strongly recommends the latest policy. The 2025 policies exclude diffie-hellman-group14-sha1, hmac-sha1 and umac-* MACs, and add hybrid mlkem key exchange. Test legacy partner clients against it first.
• KMS: if the bucket uses SSE-KMS, user roles need the matching KMS permissions; scope them to the one key.
• Bucket policy: block public access, enable versioning on landing buckets, and scan inbound files before downstream systems consume them.

Rollout order

1. Inventory servers, endpoint types, security policies, identity providers, users, roles and keys.
2. Move every user to logical directories and a role scoped to its own prefix; test with a second user that cross-access fails.
3. Set the latest security policy on a test server, connect with each partner's client, then change production in a maintenance window. Rollback is a policy change back to the previous name.
4. Migrate public endpoints to internet-facing VPC endpoints with Elastic IPs, giving partners the new addresses in advance; keep the old server until traffic moves.
5. Harden custom IdP code (invocation policy, context checks, no event logging) and turn on structured logging with alerts.

Small versus large: a handful of partners works well with service-managed users, per-user roles and an internet-facing VPC endpoint. Hundreds of users, MFA or corporate federation call for a custom identity provider built from the AWS toolkit, shared roles with session policies or logical directories, and a dedicated account.

Common misconfigurations

• One role for all users with bucket-wide access: any partner can read every other partner's files.
• PATH home directories: users see real bucket names and, with some clients, navigate above their home folder.
• Custom IdP that logs the whole event: plaintext passwords end up in CloudWatch Logs readable by many engineers.
• Lambda invocation open to the account: no AWS:SourceArn condition on the function's resource policy.
• CloudFormation default security policy: servers built from templates silently get TransferSecurityPolicy-2018-11, the only policy that still includes diffie-hellman-group14-sha1 and hmac-sha1.
• Orphaned partner keys: contracts end, keys remain. File transfer systems are a prized target; see the Managed File Transfer (MFT) Security Guide for the wider incident history.

Framework mapping

Practitioner checklist

• Every user on LOGICAL home directories with a chroot mapping.
• Roles or session policies scoped to each user's prefix; cross-user access tested and denied.
• iam:PassRole for Transfer limited to named user roles; alerts on user creation and key import.
• Security policy set explicitly to a 2025 policy (FIPS variant where required), including in CloudFormation.
• VPC endpoint with an explicit security group listing partner CIDRs; no plain FTP on internet-facing servers.
• Custom IdP: invocation limited by AWS:SourceArn, exact server ID and source IP checks, no event logging.
• SSH keys with owner and expiry; overlapping rotation; removal at contract end.
• AS2 on AES256 and SHA256 or stronger, certificate expiry tracked, connector secrets scoped.
• JSON structured logging on, with alerts for authentication failures and unusual volumes.

Standards and references

• AWS: Using AWS Lambda to integrate your identity provider
• AWS: Working with custom identity providers
• AWS: Creating a session policy for an Amazon S3 bucket
• AWS: Using logical directories to simplify your Transfer Family directory structures
• AWS: Security policies for AWS Transfer Family servers
• AWS: Create a server in a virtual private cloud
• AWS: Configuring AS2
• AWS: Managing SSH and PGP keys in Transfer Family

Related NHI Mgmt Group resources: Managed File Transfer (MFT) Security Guide, SSH Key Management Guide, AWS Security Guide, Secrets Management Guide.