SS-26-001 Automation Cloud Credential Rotation

Issue Date:  3/31/2026

PURPOSE                             

To ensure the State of Georgia’s information remains reliable, available, and protected, the GETS Architecture and Security Program requires a standardized approach for automatically rotating credentials in cloud environments.

This standard ensures credentials are rotated securely and consistently across cloud platforms and aligns with industry security best practices and applicable regulatory requirements.

SCOPE and AUTHORITY 

O.C.G.A 50-25-4(a)(9) – State Government, Georgia Technology, General Powers

O.C.G.A 50-25-4(a)(20) - State Government, Georgia Technology, General Powers

PM-04-001 – Information Technology Policies, Standards and Guidelines

PS-08-005 – Enterprise Information Security Policy

STANDARD 

1. Introduction

This standard provides best practices and baseline procedures for credential rotation for web, application, and database services within cloud-based environments.

Credential rotation applies to (at minimum):

  • Database credentials
  • Service account credentials
  • API keys and access keys
  • Application secrets (tokens, encryption keys where applicable)
  • Machine-to-machine credentials

AWS

2.AWS Credential Rotation Best Practices

AWS credential rotation should be performed using managed services where possible (e.g., AWS Secrets Manager), and rotation must be automated for privileged, service, and machine credentials.

2.1 AWS – Credential Rotation (RDS)

Use AWS Secrets Manager automatic rotation for Amazon RDS and Aurora databases.

  1. Create and store the secret
  2. In Secrets Manager, select Store a new secret
  3. Choose Credentials for RDS database
  4. Enter the DB username/password and DB endpoint information
  5. Attach required permissions and networking
    • Note: If the database is in a VPC, the rotation Lambda must have VPC access (subnets + security groups).
  6. Enable rotation
  7. In the secret, select Rotation, then Enable automatic rotation
  8. Select a rotation schedule (recommended: every 90 days unless stricter requirements apply)
  9. Choose an AWS-provided Lambda rotation function template (the console can create this automatically)
  10. Update the application configuration

Note: Applications must retrieve secrets at runtime (or via a supported caching client) rather than using hardcoded credentials

2.2 AWS – Credential Rotation (IAM Access Keys / API Keys)

IAM access keys should be avoided for workloads where possible and replaced with:

  • IAM Roles (preferred)
  • STS short-lived credentials

If access keys must be used:

  1. Store the credential in AWS Secrets Manager
    • JSON format is common (example: { "accessKeyId": "...", "secretAccessKey": "..." })
  2. Create a custom rotation Lambda function
  3. Configure the secret’s rotation schedule to invoke the Lambda
  4. Ensure the Lambda:
    • Creates a new access key
    • Updates the secret
    • Validates usage
    • Disables and deletes the old access key

2.3 AWS – Credential Rotation (Applications / Services)

  1. Applications must fetch secrets dynamically using the AWS SDK
  2. If secrets are cached:
    • Refresh periodically, or
    • Use the AWS Secrets Manager caching client
  3. If the application cannot tolerate immediate cutover:
    • Implement short overlap windows (“old password works for N minutes”) where supported
  4. Apply least privilege:
    • Applications should only have secretsmanager:GetSecretValue for the specific secret ARN
  5. Enable logging:
    • CloudTrail logging must be enabled to capture access to Secrets Manager and rotation events

2.4 AWS – Credential rotation on EC2 using SSM

  1. Create a role
  2. Create a Secrets Manager secret
  3. Create an SSM Automation document
  4. Schedule rotation

Azure

3. Azure Credential Rotation Best Practices.

3.1 Azure – Credential Rotation (Key Vault + Automation / Functions)

Recommended services:

  • Azure Key Vault
  • Azure Automation or Azure Functions
  • Managed Identities (preferred over stored credentials)

Best practices:

  • Store secrets in Azure Key Vault
  • Configure applications to retrieve secrets dynamically from Key Vault
  • Use Azure Functions or Azure Automation to rotate credentials on a schedule
  • Rotation automation must:
    • Generate a new credential
    • Update Key Vault secret value
    • Validate dependent application/service functionality
    • Disable/revoke the old credential
  • Ensure Key Vault auditing is enabled via:
    • Azure Monitor
    • Log Analytics
    • Diagnostic settings

3.2 Azure – Rotation Guidance by Credential Type

Common credential types requiring rotation:

  • SQL database users (Azure SQL / SQL MI)
  • Storage account keys (if not using Managed Identity)
  • App registration secrets / certificates
  • Service principal secrets (avoid where possible)

Preferred approach:

  • Use Managed Identity instead of service principal secrets whenever supported.

3.3 Azure – Credential rotation on a VM using Key Vault

  • Create a role
    • System Assigned Managed Identity on the VM or Automation Account
    • RBAC permissions to Key Vault + VM actions
    • Enable Managed Identity
    • Grant:
      • Key Vault Secrets Officer
      • VM permissions if needed (Run Command)
  • Create a Key Vault secret
  • Create an Automation workflow 
    • Azure Automation Runbook
  • Schedule rotation
  • Azure Automation Schedule 
  • Logic App schedule
  • Azure Functions timer trigger

GCP

4. GCP Credential Rotation Best Practices.

4.1 GCP – Credential Rotation (Scheduler + Functions)

Required services:

  • Secret Manager
  • Cloud Scheduler
  • Cloud Functions (or Cloud Run)
  • IAM permissions for the rotation workflow

Applications must be configured to retrieve secrets:

  • At startup, OR
  • Dynamically on demand, OR
  • Always request the latest version

Rotation process:

  • Generate a new credential
  • Store it as a new secret version in Secret Manager
  • Update workloads to use the new version
  • Validate functionality
  • Disable or delete the old credential

4.2 GCP – Credential Rotation (Console)

  • In the Google Cloud Console, go to Secret Manager
  • Locate the secret to update
  • Open the Actions menu and select Edit
  • Go to the Rotation section
  • Update the rotation period as required and select Update secret

4.3 GCP – Credential Rotation on Virtual Machines

  • Create a “role” (Service Account)
  • Grant least-privilege roles:
    • roles/secretmanager.secretAccessor
    • roles/secretmanager.secretVersionAdder
    • roles/compute.instanceAdmin.v1
  • Attach the Service Account to the VM or cloud function.
  • Create a Secret Manager secret
  • Create the Automation
    • Cloud Function + OS Login
    • Cloud Workflows + Compute Engine API
  • Schedule rotation every 30 / 60 / 90 days accordingly.

5 Compliance Requirements

5.1 Credential Rotation Compliance

The following compliance frameworks commonly require automatic password rotation for privileged credentials, service accounts, and machine credentials (examples include database credentials, API keys, and service accounts):

  • NIST 800-53
  • CJIS
  • PCI DSS
  • SOC 2
  • ISO 27001

6 Additional Recommendations 

6.1 Rotation Frequency

Unless otherwise required by policy, contract, or system classification:

  • Standard credentials: rotate every (90 days)
  • Privileged/admin credentials: rotate every (30–60 days)
  • Break-glass accounts: rotate immediately after use.

6.2 Logging and Monitoring

  • Credential access and rotation events must be logged and retained according to policy: 
  • Rotation logs must be retained for 1 year
  • Evidence must show:
  • last rotation date
  • next scheduled rotation
  • success/failure status
  • Logging services overview
    • AWS: CloudTrail, Secrets Manager logs, Splunk
    • Azure: Key Vault diagnostics, Log Analytics, Splunk
    • GCP: Cloud Audit Logs, Secret Manager audit logs, Splunk
    1. Failure handling
  • Alerting required for failed rotation
  • Incident escalation rules
  • Rollback guidance (restore old secret version temporarily)
    1. Rotation evidence and auditing
  • Rotation logs must be retained for 1 year
  • Evidence must show:
    • last rotation date
    • next scheduled rotation
    • success/failure status

6.3    Rotation must be zero-downtime

  • Rotation must not cause outages
  • Apps must support retrieving updated secrets without redeploy where possible
    1. Secret retrieval requirement scenarios
  • Hardcoded credentials in code
  • Secrets stored in environment variables permanently
  • Secrets stored in Terraform state
  • Secrets stored in GitHub Actions secrets as the “source of truth”

RELATED ENTERPRISE POLICIES, STANDARDS AND GUIDELINES

Cryptographic Controls (SS-08-040)

Certificate Standards (GS-25-07)

REFERENCES