Beyond Secrets Manager: Designing Zero-Retention Secrets in AWS With Ephemeral Access Patterns

Secrets management in AWS has traditionally relied on long-lived secrets stored in Secrets Manager or Parameter Store. But as attack surfaces grow and threat actors become faster at exploiting exposed credentials, even rotated secrets begin to look like liabilities. The future of security in AWS leans toward ephemeral access, where credentials are generated just-in-time, scoped to the minimum needed permission, and vanish as soon as they are no longer needed.

This article explores how to build a zero-retention secrets architecture in AWS, one that minimizes persistent secrets and instead leverages IAM roles, STS, session policies, and Lambda-based brokers. No Vault, no standing tokens, just-in-time, context-aware access.

Why Secrets Rotation Is No Longer Enough

Rotating secrets reduces their exposure, but it does not eliminate risk. Credentials still exist. They can be mishandled, copied, or leaked, intentionally or otherwise. AWS Secrets Manager encrypts values and automates rotation, but the secret is still a retrievable object.

What if credentials were never persisted at all? What if they were issued dynamically for each session and expired within minutes? This is the goal of zero standing privileges (ZSP), a principle being adopted by security-forward organizations, particularly in cloud-native infrastructures.

Furthermore, secrets rotation creates operational debt. Every rotation introduces new failure points, downstream systems may not be ready for key updates, integrations may lag, and fallback mechanisms can reintroduce old credentials. Ephemeral credentials eliminate this complexity by ensuring secrets never need to be stored in the first place.

Pattern Overview: AWS-Native Ephemeral Access Flow

At the heart of this architecture is AWS Security Token Service (STS). STS allows a trusted entity to request temporary credentials by assuming a role. When scoped tightly with IAM conditions and session policies, this becomes a robust, scalable access mechanism.

The typical flow looks like:

[Application/User] → [Broker Lambda] → [STS AssumeRole] → [Session Credentials]

These credentials can be scoped to expire in as little as 900 seconds, and they never need to be stored. All sensitive permissions are granted dynamically, only when needed. This approach aligns perfectly with the principle of least privilege and supports runtime policy enforcement.

Ephemeral access is particularly valuable for:

• Temporary cross-account access
• Developer sandbox environments
• Internal microservices authentication
• Break-glass admin workflows

Defining a Role for Ephemeral Access

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "prod-access"
        }
      }
    }
  ]
}

This trust policy restricts which principals can assume the role, using ExternalId to add a shared secret for verification. You can also limit usage by IP address, time of day, or session tags.

Issuing Session Credentials via Lambda Broker

import boto3

def handler(event, context):
    client = boto3.client('sts')
    response = client.assume_role(
        RoleArn='arn:aws:iam::123456789012:role/temp-access-role',
        RoleSessionName='brokered-access',
        DurationSeconds=900
    )
    return {
        'AccessKeyId': response['Credentials']['AccessKeyId'],
        'SecretAccessKey': response['Credentials']['SecretAccessKey'],
        'SessionToken': response['Credentials']['SessionToken']
    }

This broker can apply additional logic: enforce MFA, log access requests, or attach session policies. It serves as a policy-aware gatekeeper between users and IAM roles.

Scoping Temporary Credentials With Session Policies

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::secure-audit-logs/*"
    }
  ]
}

This policy attaches to the temporary credentials, restricting them to only specific actions (like writing to an S3 bucket) during that session. You can dynamically apply such constraints based on session context.

Runtime Config via SSM Parameter Store

aws ssm get-parameter \
  --name "/app/runtime/feature_flag" \
  --with-decryption \
  --query "Parameter.Value"

Instead of using Secrets Manager, short-lived apps can pull runtime config via SSM and discard it when the session ends. Since values are never persisted to disk, this minimizes exposure.

Ops Tips: Migrating to Ephemeral Access

Going from long-lived credentials to session-based access is not just a code change; it’s a culture shift. Start small:

• Replace internal Secrets Manager usage with STS-based access.
• Ensure apps refresh credentials automatically before TTL expiry.
• Rotate IAM roles used for assumption every 90 days.
• Monitor CloudTrail for long-lived session abuse.

Leverage AWS Config to detect hardcoded credentials or unused roles. Use Access Analyzer to audit resource policies and remove excessive trust relationships. Apply Conditions on AssumeRole to enforce compliance.

For CI/CD pipelines, use temporary credentials from a centralized credential broker rather than hardcoded values in environment variables. Ensure developers follow the same ephemeral model using AWS CLI AssumeRole profiles.

Session credentials should not be logged, cached, or stored; they should only be passed in memory.

What's Next: Just-in-Time Secrets and Identity-Aware Access

The future of AWS security is ephemeral. Instead of secrets that outlive their use, services are moving toward:

• IAM session tags for dynamic scoping
• Just-in-time service access based on policy and intent
• Temporary credentials bound to workflow state

Tools like Akeyless, StrongDM, and AWS-native integrations with IAM Identity Center are all part of this push. These patterns reduce breach windows from days to seconds.

AWS’s integration with attribute-based access control (ABAC) also enables secrets access to be tightly coupled with identity metadata, like project tags, environment labels, or developer group membership, enabling fine-grained access without manual policy rewrites.

Design for Ephemerality

Secrets that do not exist cannot be leaked. By designing AWS systems with zero retention in mind, security teams can reduce credential risk, simplify audits, and align with least privilege principles.

The takeaway: ephemeral access is not a luxury; it is rapidly becoming a security baseline. If your AWS systems still depend on Secrets Manager for runtime credentials, it may be time to rethink the pattern.

Just-in-time identity-aware security patterns offer a blueprint for what modern cloud security should look like. The time to move is before the next breach, not after.