PowerShell Workflows for Azure Key Vault Secret and Certificate Rotation

Azure Key Vault gives administrators a central place to store passwords, API keys, connection strings, certificates, and encryption material. PowerShell adds a repeatable way to inspect vault objects, create new versions, update dependent services, and record rotation activity without handling sensitive values manually.

A reliable design separates secret rotation from certificate lifecycle management. A secret usually needs a new value and a controlled application update. A certificate also involves an expiry date, a private key, an issuing policy, and a process for making the renewed version available to workloads.

For Australian organisations, the design may need to align with the Essential Eight, APRA CPS 234, internal separation-of-duties controls, and data residency requirements. Azure Australia East in Sydney and Australia Southeast in Melbourne are common choices, while scheduled jobs should account for AEST and AEDT changes.

Prepare PowerShell And Key Vault Access

Install or update the Az modules on the workstation, automation worker, or pipeline agent that will run the rotation job:

Install-Module Az.Accounts, Az.KeyVault -Scope CurrentUser -Repository PSGallery
Connect-AzAccount
Set-AzContext -SubscriptionId "00000000-0000-0000-0000-000000000000"

For unattended execution, use a managed identity wherever possible. An Azure Automation account, virtual machine, Function App, or DevOps workload identity can authenticate without storing a client secret in the script. Assign the identity the smallest suitable Azure role, such as Key Vault Secrets Officer for secret operations or Key Vault Certificates Officer for certificate operations.

Prefer Azure role-based access control over broad legacy access policies in new deployments. Grant Key Vault Secrets User to applications that only read secrets, and reserve write permissions for the rotation identity. Diagnostic logging should be sent to a protected Log Analytics workspace, with retention matching the organisation’s regulatory and operational requirements.

Read And Update Secret Values Safely

Retrieve a secret as a SecureString, and avoid writing the plain-text value to the console, transcript, pipeline log, or temporary file:

$vaultName = "kv-prod-aue-01"
$secretName = "payment-api-key"

$secret = Get-AzKeyVaultSecret `
    -VaultName $vaultName `
    -Name $secretName

$plainText = $secret.SecretValue | ConvertFrom-SecureString -AsPlainText

The last conversion should occur only at the point where a target system requires the value. A rotation script can generate a new value, pass it directly to an API, and then store it in Key Vault. When creating a new version, use Set-AzKeyVaultSecret with a secure value:

$newValue = [Guid]::NewGuid().ToString("N")
$secureValue = ConvertTo-SecureString $newValue -AsPlainText -Force

Set-AzKeyVaultSecret `
    -VaultName $vaultName `
    -Name $secretName `
    -SecretValue $secureValue `
    -Tag @{ RotatedBy = "PowerShell"; Environment = "Production" }

A new Key Vault secret version does not automatically update an application that has cached the old value. Applications should retrieve the current version at startup or on a controlled refresh interval. Where an application stores a version-specific URI, update that configuration as part of the same change process.

Detect Certificates Near Expiry

Certificate objects expose expiry and policy information that can drive a renewal report:

$certificate = Get-AzKeyVaultCertificate `
    -VaultName $vaultName `
    -Name "web-tls"

$daysRemaining = ($certificate.Expires - (Get-Date)).Days

[pscustomobject]@{
    Name          = $certificate.Name
    Version       = $certificate.Version
    Expires       = $certificate.Expires
    DaysRemaining = $daysRemaining
}

A practical threshold is 30 or 45 days, although public certificate authorities, internal PKI procedures, and application testing windows may require more time. Check the certificate’s issuer, key type, subject alternative names, and exportability before attempting renewal. A certificate used by an Azure Application Gateway, an IIS server in Brisbane, or a load balancer in a Melbourne data centre may each require a different deployment step.

Key Vault can renew certificates automatically when the certificate policy and issuer support that capability. For imported certificates, PowerShell generally needs to upload the replacement PFX or coordinate with the organisation’s certificate authority. Renewal in Key Vault is only one part of the process; the new version must reach the service terminating TLS.

Rotate Certificate Versions Without Service Disruption

For a certificate managed by an integrated issuer, inspect the policy before starting a renewal operation:

$policy = Get-AzKeyVaultCertificatePolicy `
    -VaultName $vaultName `
    -Name "web-tls"

$policy | Format-List

The exact renewal command depends on the Az.KeyVault module version and issuer configuration. A common workflow uses the certificate operation cmdlets to start or request renewal, then polls until the operation completes. Always test the resulting certificate in a non-production vault before changing a production endpoint.

For an externally issued certificate, validate the replacement PFX before importing it. The import job should check the subject, SAN entries, issuer chain, expiry, and private-key presence. After importing, retrieve the new version identifier and update the consuming service. Keep the previous version enabled during the cutover so rollback remains possible, then remove or disable it according to the organisation’s retention policy.

Automate Rotation With PowerShell

Azure Automation is suitable for scheduled rotation jobs that use a system-assigned managed identity. A runbook can authenticate with Connect-AzAccount -Identity, inspect secrets and certificates, perform only due rotations, and write structured status records. Store the runbook code in source control and use a separate test vault for validation.

A pipeline is useful when rotation requires approval, application deployment, or integration tests. Azure DevOps and GitHub Actions can use workload identity federation instead of long-lived service-principal credentials. Build the process so that a failed application update stops the next step rather than disabling the previous certificate immediately.

Use an idempotent design. The job should safely run twice, identify the current version, avoid creating unnecessary replacements, and record a correlation ID. Schedule it outside peak business hours in the relevant Australian time zone, while remembering that a Sydney-based team moves between AEST and AEDT during daylight-saving months.

Rotation Runbook Essentials

A pre-rotation check should confirm access, dependencies, and the intended change window:

• Confirm the managed identity and Key Vault RBAC assignments
• Check certificate issuer, SANs, key type, and expiry
• Verify the target application can reload configuration
• Confirm backup, rollback, and monitoring procedures

Post-rotation validation should prove that the new version is usable rather than merely present in the vault:

• Test the application’s authenticated connection
• Verify the active certificate chain and expiry date
• Review Key Vault and application diagnostic logs
• Record the new version and retirement date

For regulated environments, retain evidence of who or what performed the operation, which vault and subscription were used, and whether the old credential was revoked. APRA-regulated businesses may map these records to CPS 234 control evidence, while public-sector teams may need additional alignment with IRAP assessment practices.

A measured rollout works well for hybrid estates. Rotate the Key Vault object first, update a staging workload, then deploy to production services across regions such as Australia East and Australia Southeast. This approach limits the blast radius and provides a clear recovery path if an application in Sydney, Melbourne, or a remote office fails to accept the new credential.