What’s the safest way to handle credentials in automation scripts?

For a simple PowerShell-only solution, you can create a credential object with Get-Credential and save it using Export-Clixml. Import-Clixml can then load it when the script runs. The encrypted data is tied to the Windows account and machine that created it, so this is not a portable backup and should be protected with appropriate file permissions.

PowerShell’s SecretManagement framework is another practical option. It lets the script retrieve secrets at runtime through a configured vault instead of keeping them in source files. Whichever method you choose, also protect the script, limit logging of command arguments and variables, use least-privilege accounts, and remember that anyone who fully compromises the jump server may be able to access secrets while the automation is running.

The better long-term approach is to avoid embedding passwords altogether. Use a secrets manager or vault, such as an enterprise password vault, Azure Key Vault, or HashiCorp Vault for on-premises environments. The automation account should authenticate to the vault using integrated authentication, a certificate, or another non-password method, and should receive only the minimum secret access it needs.

If the script runs as a scheduled task in a Windows domain, consider using a group Managed Service Account. Grant that account the required permissions on the target system, then run the automation under it. This avoids having to store a reusable password in the script. Be sure to limit the account’s privileges and restrict which machines are allowed to use it.