Encrypted systemd Credentials Still Become Service-Accessible Data
LoadCredentialEncrypted= is designed to keep a credential encrypted at rest until a service starts. systemd decrypts and authenticates the credential, then passes it to the executed process through ${CREDENTIALS_DIRECTORY}. The approach can remove plaintext secrets from a configuration file or a manually managed path, but the service receives usable data once it runs.
That lifecycle is the security model. The host needs the encryption key, the service manager performs the decryption, and the service process can read the result. If the process is compromised after startup, the credential is no longer protected by the encrypted file's ciphertext.
What encrypted loading provides
The systemd documentation says LoadCredentialEncrypted= is identical to LoadCredential= except that the referenced credential is decrypted and authenticated before it is passed to the service. The credential may be encrypted with a key derived from the TPM2 chip, a host secret, or both, depending on the configuration.
Recent systemd documentation also describes additional binding to the TPM2 storage root key in version 262 and later to defend against certain interposer attacks during decryption. That is a useful improvement in the host trust model, not a reason to skip file permissions, service isolation, or credential rotation.
The service receives a credential directory rather than a literal secret in the unit file. This lets an operator keep ciphertext in a controlled location and avoid embedding plaintext in SetCredential=. It also gives the deployment a clear place to document the credential name and its consumer.
The process is now the boundary
After startup, the service can read the credential. Any code running in the same process, any child that inherits the credential directory, and any debugger or memory-dumping tool with sufficient privilege may also reach it. The unit's User=, Group=, PrivateTmp=, filesystem view, and child-process policy still matter.
A service that loads a database password into an environment variable and then launches a general-purpose shell has undone much of the benefit. A worker that copies the credential into a log message has done the same. Review the complete data flow:
- where the credential is stored before decryption;
- which unit loads it;
- which process reads it;
- whether child processes inherit it;
- whether application logs, crash reports, or tracing include it;
- how the credential is rotated and the service restarted.
The unit file should not reveal the plaintext. Application diagnostics should reveal only the credential name or a fingerprint approved for that purpose, never the value.
Availability and host binding
Encrypted credentials can fail when the TPM2 device, host key, or expected machine identity is unavailable. A migrated virtual machine or a restored host may not decrypt the credential. These are expected consequences of binding a secret to a host, and they need an explicit recovery procedure.
Do not make the recovery path a permanent plaintext copy in a shared directory. If a break-glass credential is necessary, store it under a separate owner, restrict who can use it, and require an audit record. After recovery, return to the encrypted path and rotate the exposed credential if the break-glass material could have been read by an unauthorized party.
Test decryption on the actual host image and with the same service manager version. A successful unit parse is not proof that the credential is available to the service. Check the service's startup logs for a clear failure, then verify that a permitted read occurs inside the service's expected identity.
Rotation and verification
A credential rotation should include the encrypted copy, the service unit, the application's cached state, and any dependent workers. If the application keeps the old password in a connection pool, restarting the unit may not be enough. Confirm that the old credential no longer authenticates and that new connections use the new one.
Use a verification command that proves the service can read its own credential without printing the secret. Check the directory's ownership and permissions from inside the service context, then exercise the downstream operation that needs the credential. Record the version or hash of the encrypted blob, not the plaintext.
The practical rule
Encrypted systemd credentials improve how a secret is stored and delivered. They do not erase the need to treat the running service as a holder of authority. Keep the decrypted lifetime short where possible, isolate the process, remove unnecessary child execution, and make rotation a tested operation. The secure part is the whole lifecycle, not just the encrypted file on disk.
