Credential best practices
Store credentials once and reuse them safely. Use service accounts, least privilege, and one credential per system — and rotate on your normal schedule.
Last updated July 17, 2026
#How credentials are stored
Credentials are encrypted on the FileAgent host and referenced by jobs. Secrets are never embedded in job definitions and are never shown back in full in the console. Editing a credential applies to every job that uses it, so a password rotation is a single change. See Credential & data protection for the security model.
#Practices that keep you safe
- Use service accounts, never personal logins. People leave; jobs shouldn't break when they do.
- Least privilege. Read on sources, write on destinations, delete only where Move, Sync/Mirror, or Purge requires it.
- One credential per system or partner. Don't share one account across unrelated workflows — blast radius matters.
- Prefer keys and scoped tokens where supported (SFTP private keys, container-scoped Azure SAS tokens, prefix-scoped S3 policies).
- Rotate on your normal schedule — edit the credential, test, done.
- Limit who can manage credentials with FileAgent roles, and protect the host itself.
#Editing and deleting
Editing a credential affects every job that uses it — re-test the connection after saving. Deleting a credential that jobs still reference will break those jobs at their next run, so reassign or disable dependent jobs first.
Before deleting a credential, check the Jobs list for anything still pointing at it.