AWS Secrets Manager: Storing, Rotating and Auditing Secrets on AWS

Moving database passwords and API keys into AWS Secrets Manager removes them from code and config files, but it also creates one place where a single over-broad IAM permission can hand an attacker every credential the organisation owns. Secrets Manager is AWS's native store for machine credentials: it encrypts each secret with AWS KMS, versions it with staging labels, rotates it on a schedule and logs every retrieval in CloudTrail. How much protection that gives depends on choices that are easy to get wrong: which KMS key encrypts the secret, who can call GetSecretValue and PutResourcePolicy, how rotation is built and whether anyone watches the logs. This guide goes deep on Secrets Manager alone, covering its access model, privileged roles, rotation, logging and a hardening baseline. It is written for AWS platform, security and application teams.

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

• The KMS key is part of the access policy. The AWS managed key aws/secretsmanager is free but cannot be used for cross-account access; a customer managed key lets you add a key policy and kms:ViaService conditions as a second, independent gate.
• PutResourcePolicy is a privilege escalation path. AWS warns that a principal holding it can rewrite a secret's resource policy and take full control, so require BlockPublicPolicy and restrict the action to administrators.
• Rotation is only safe if the application tolerates it. Choose single user or alternating users deliberately, cache secrets with the AWS caching components and test rotation before you schedule it, which can be as often as every four hours.
• Every read is an audit event. GetSecretValue and BatchGetSecretValue appear in CloudTrail, and bulk reads across many secrets from one identity are among the clearest signals of compromise.
• Metadata is not secret. Only the secret value is encrypted; names, descriptions, tags and rotation settings are not, so never put sensitive data in them.

How identity and access work in AWS Secrets Manager

A request to read a secret succeeds only if every applicable policy allows it. Treat each layer as a separate control rather than relying on one.

Encryption model. Secrets Manager uses envelope encryption: KMS generates a 256-bit AES data key for each new secret value, the value is encrypted outside KMS, and the encrypted data key is stored in the secret's metadata. Every GenerateDataKey and Decrypt call carries an encryption context of SecretARN and SecretVersionId, which you can use as a policy condition and to tie KMS events in CloudTrail to a specific secret. Only symmetric KMS keys are supported, and a customer managed key must be in the same account and Region as the secret.

Cross-account access needs four pieces. AWS documents a resource policy on the secret allowing the external principal, a customer managed key, a key policy granting that principal kms:Decrypt (plus kms:GenerateDataKey if it writes), and an identity policy in the other account allowing both the secret and the key. Verify the result with IAM Access Analyzer. See the IAM Access Analyzer Guide.

Admin roles and privileged access

AWS's own guidance for administrators is the SecretsManagerReadWrite and IAMFullAccess managed policies, the latter because enabling rotation creates roles, and it recommends against giving them to end users. Both are broader than most organisations need day to day, so split the work.

Watch the destructive actions too. DeleteSecret schedules deletion after a recovery window of at least seven days, during which the secret is inaccessible but restorable; --force-delete-without-recovery deletes it permanently. Restrict force deletion with an SCP, and remember that a primary secret cannot be deleted while replicas exist. See the AWS Organizations and SCPs Guide and the AWS IAM Identity Center Guide.

Integrations, API tokens and service accounts

Secrets Manager mostly stores credentials for non-human identities, and the way workloads fetch them decides whether the secret stays secret.

• Caching components: AWS lists client-side caching for Java, Python, .NET, Go and Rust, the AWS Parameters and Secrets Lambda Extension, Secrets Manager in Amazon EKS and the AWS Workload Credentials Provider. Caching cuts API calls and cost, and lets applications pick up rotated values without redeploying.
• Containers and Kubernetes: fetch secrets at runtime with the workload's own IAM role rather than baking them into images or environment files. See the AWS Lambda Security Guide for function patterns.
• Managed secrets and managed rotation: some AWS services create and rotate secrets on your behalf (managed rotation, no Lambda function), and managed external secrets rotation updates credentials held by Secrets Manager partners. Prefer these where available: there is no rotation code for you to maintain.
• Rotation Lambda functions: the function is itself a privileged service identity. It needs to read and write the secret and change the password on the target database or service, and if it runs in a VPC it needs a route to Secrets Manager (interface endpoint or NAT) and to the target. For alternating users rotation it also reads a separate superuser secret.
• CI/CD pipelines: pipelines that create or update secrets should use OIDC federation, not stored access keys. See How to set up workload identity federation for GitHub Actions to AWS.
• The bootstrap problem: the workload still needs an identity to call Secrets Manager. On AWS that should be an instance profile, task role, IRSA or Pod Identity role, never a long-lived key stored next to the application. See the Secrets Zero Problem Guide.
• CLI hygiene: AWS notes that command shells can log commands and expose recently entered values, so avoid passing secret values as CLI arguments on shared hosts.

Rotation in practice

Each secret keeps versions tracked by staging labels: AWSCURRENT (returned by default, always present), AWSPREVIOUS and AWSPENDING (used during rotation). A Lambda rotation function is called four times with the steps create_secret, set_secret, test_secret and finish_secret; if any step fails, Secrets Manager retries the whole rotation during the rotation window.

Rollout order: enable rotation in a non-production account, confirm every consumer uses a caching client or re-reads on authentication failure, run a manual rotation and watch for RotationFailed, then set the schedule. Rollback is to move the AWSCURRENT label back to the previous version with UpdateSecretVersionStage while the cause is fixed. Unlabelled versions are deprecated and removed when a secret has more than 100 versions, so do not rely on old versions as a backup. See the Secrets Rotation Runbook Template.

Logging and detection

AWS also lists CloudWatch, AWS Config compliance rules and Amazon GuardDuty for monitoring secrets, and recommends a CloudWatch alarm on access attempts to secrets scheduled for deletion to find forgotten consumers. Map detections to T1555.006 Cloud Secrets Management Stores and T1078.004 Cloud Accounts. See the AWS CloudTrail Guide and the AWS Config Guide.

Metrics that show it is working:

• Percentage of secrets with automatic rotation enabled and a successful rotation inside the policy period.
• Number of identity policies granting secretsmanager:GetSecretValue on * (target: zero outside break-glass).
• Percentage of high-value and cross-account secrets on customer managed keys with kms:ViaService conditions.
• Secrets not read in 90 days (candidates for deletion) and hardcoded credentials found by code scanning per month.
• Mean time to detect a bulk-read pattern in exercises.

Hardening baseline

1. Inventory first. List every secret with its owner tag, KMS key, rotation status, last accessed date and resource policy, and scan code and pipelines for hardcoded credentials (AWS points to the CodeGuru Reviewer secrets detector and Amazon Q). See the Secret Sprawl Measurement Guide.
2. Name and tag for access control. Adopt a path convention such as prod/payments/ and owner and environment tags, so policies can be scoped by ARN prefix or tag.
3. Choose keys. Customer managed keys with kms:ViaService for production and shared secrets; optionally deny use of aws/secretsmanager in production accounts, as AWS's IAM examples show.
4. Scope workload access. One role per workload, GetSecretValue on its own secrets only, with an aws:SourceVpce condition where the workload runs in a VPC. Test that rotation functions and AWS services still work before enforcing network conditions.
5. Guard resource policies. Require BlockPublicPolicy on every PutResourcePolicy grant, alert on resource policy changes, and review cross-account access with IAM Access Analyzer.
6. Enable rotation in rings. Non-production, then low-risk production, then the rest, with caching clients deployed first and rollback by staging label documented.
7. Replicate deliberately. Replicate only secrets needed for multi-Region recovery, and include the replica Regions in your monitoring scope.
8. Protect deletion. SCP deny on ForceDeleteWithoutRecovery outside break-glass; alarms on deletion and on access to deleted secrets.
9. Keep secrets out of metadata. Names, descriptions and tags are not encrypted.

Common misconfigurations

• Wildcard read access: a workload role with GetSecretValue on * turns one compromised host into a full credential dump. In the AI Agent Retail Card Theft Campaign 2026, attackers dumped every Secrets Manager secret they could reach, 46 in one case, and used them to reach the payment database.
• Uncontrolled PutResourcePolicy: developers or pipelines able to edit resource policies can grant themselves or an external account access, which AWS explicitly flags as escalation.
• Rotation enabled before consumers are ready: applications that read the secret once at start-up fail after the first rotation, and teams respond by disabling rotation permanently.
• Secrets copied out after retrieval: values written to environment variables, logs or build artefacts escape all the controls above.
• Cross-account sharing on the wrong key: teams discover that aws/secretsmanager cannot be shared and then copy the secret into the other account, creating two unrotated copies.
• Encryption keys stored beside the data they protect: an application encryption key in the same reachable store as the credentials to the encrypted data defeats the point of encrypting it.

Framework mapping

In ISO/IEC 27001:2022 terms this supports Annex A 5.17 (authentication information), 8.24 (use of cryptography) and 8.15 (logging).

Practitioner checklist

• Every secret has an owner tag, an environment path and a documented consumer list.
• No identity policy grants GetSecretValue on *; workload roles are scoped to their own secrets.
• Production and cross-account secrets use customer managed keys with kms:ViaService.
• PutResourcePolicy allowed only with BlockPublicPolicy, and only to administrators.
• Interface VPC endpoint in use, with aws:SourceVpce conditions tested against rotation functions.
• Rotation enabled with the right strategy, caching clients in place and staging-label rollback documented.
• CloudTrail alerts for bulk reads, resource policy changes, rotation failures and deletions.
• Force deletion blocked by SCP outside break-glass.
• Code and pipelines scanned for hardcoded credentials, with findings migrated into Secrets Manager.
• No sensitive data in secret names, descriptions or tags.

Standards and references

• AWS Secrets Manager User Guide: Best practices
• AWS Secrets Manager User Guide: Secret encryption and decryption
• AWS Secrets Manager User Guide: Cross-account access
• AWS Secrets Manager User Guide: Rotation strategies
• AWS Secrets Manager User Guide: What's in a secret
• AWS Secrets Manager User Guide: CloudTrail entries
• MITRE ATT&CK: Cloud Secrets Management Stores
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Cloud Secrets Managers Guide · Secrets Management Guide · AWS KMS Security Guide · AWS Security Guide