Create a SQL Server credential with T-SQL or Management Studio and use it for Agent proxies and backups to Azure Blob Storage or S3, then change or remove it safely.
A credential stores a user name and secret that SQL Server uses when it has to authenticate to something outside itself: a file share, an operating-system command run by a job, Azure Blob Storage, an S3 bucket, a key vault. Create one with CREATE CREDENTIAL:
USE master;
GO
CREATE CREDENTIAL FileShareCred
WITHIDENTITY= N'CONTOSO\svc_sqlfiles',
SECRET = N'<password of that Windows account>';
IDENTITY is the account used outside SQL Server and SECRET is its password or key. A credential does nothing on its own. It takes effect when something refers to it: a SQL Server Agent proxy, a login, or a BACKUP ... TO URL statement.
A credential is not a login. Logins control who can connect to SQL Server; credentials control what identity SQL Server presents when it reaches out.
Creating a credential in Management Studio
In Object Explorer, expand Security.
Right-click Credentials and choose New Credential.
Enter a Credential name.
In Identity, type the Windows account (DOMAIN\user) or use the ... button to pick it.
Enter the password in Password and Confirm password, then click OK.
The dialog runs the same CREATE CREDENTIAL statement shown above. Use the Script button at the top of the dialog to see it.
What you need before you start
Permission:ALTER ANY CREDENTIAL on the server. Members of sysadmin have it.
A working account: SQL Server does not check the identity or the secret when you create the credential. A typo in the password is accepted, and you only find out when something uses the credential and fails with a logon error. Test it straight away.
Error 8152 never said which column. Message 2628 on SQL Server 2019+ (or trace flag 460 on 2016/2017) names it. Then fix the data or the column, and watch for silent truncation.
Least privilege: give the outside account only the access the task needs, such as write access to one folder. Anyone who can use the credential acts with that account's rights.
The common uses
Run an Agent job step as a different Windows account
By default, job steps that touch the operating system run as the SQL Server Agent service account. To run one as another account, wrap the credential in a proxy and allow the proxy for a subsystem:
The proxy then appears in the Run as list of CmdExec job steps. Repeat sp_grant_proxy_to_subsystem for other subsystems, for example PowerShell. The last call lets a login that is not a sysadmin use the proxy in its own jobs; sysadmins can use every proxy.
Back up to Azure Blob Storage with a shared access signature
Here the naming rules are strict:
CREATE CREDENTIAL [https://mystorageaccount.blob.core.windows.net/sqlbackups]
WITHIDENTITY='SHARED ACCESS SIGNATURE',
SECRET ='<SAS token without the leading ?>';
BACKUP DATABASE SalesDB
TO URL ='https://mystorageaccount.blob.core.windows.net/sqlbackups/SalesDB.bak'WITH COMPRESSION, CHECKSUM;
The credential name must be the container URL: it starts with https, and has no trailing slash.
IDENTITY must be the literal string SHARED ACCESS SIGNATURE.
SECRET is the SAS token with the leading ? removed.
SQL Server finds the credential by matching the backup URL against credential names, so you do not name it in the BACKUP statement.
Back up to S3-compatible object storage
SQL Server 2022 and later can back up to S3-compatible storage. The credential name is the bucket URL, and the secret is the access key ID and secret key joined by a colon:
ALTER LOGIN etl_user ADD CREDENTIAL FileShareCred;
A login can be mapped to one credential of this kind, and the same credential can be mapped to many logins. This mapping is used in a few specific places, chiefly Extensible Key Management providers such as Azure Key Vault, where the credential is created with FOR CRYPTOGRAPHIC PROVIDER and holds the key vault identity.
Managed identity
On SQL Server 2022 and later running on an Azure VM, and on Azure Arc-enabled SQL Server 2025, a credential can use the machine's managed identity, so there is no secret to store or rotate:
CREATE CREDENTIAL creates a server-level credential, stored in master and usable by the whole instance. There is also a separate statement, CREATE DATABASE SCOPED CREDENTIAL, which stores the credential inside one database.
Server-level credential
Database scoped credential
Statement
CREATE CREDENTIAL
CREATE DATABASE SCOPED CREDENTIAL
Catalog view
sys.credentials
sys.database_scoped_credentials
Moves with a database backup
No
Yes
Typical uses
Agent proxies, backup to URL, EKM
External data sources, PolyBase and data virtualization, BULK INSERT and OPENROWSET from cloud storage
Azure SQL Database
Not the form to use
Supported
If you are on Azure SQL Database, or the instructions you are following mention an external data source, you need the database scoped version.
Check, change and remove
List the credentials on the instance:
SELECT credential_id, name, credential_identity, create_date, modify_date
FROM sys.credentials
ORDERBY name;
The secret is never shown. It is encrypted with the service master key and cannot be read back, so keep it in your password manager.
To see which proxies depend on a credential:
SELECT p.name AS proxy_name, c.name AS credential_name, p.enabled
FROM msdb.dbo.sysproxies AS p
JOIN sys.credentials AS c ON c.credential_id = p.credential_id;
When the Windows password or SAS token changes, update the credential. ALTER CREDENTIAL replaces both values, so supply both. If you leave out SECRET, the stored secret is cleared:
ALTER CREDENTIAL FileShareCred
WITHIDENTITY= N'CONTOSO\svc_sqlfiles',
SECRET = N'<new password>';
To remove one:
DROP CREDENTIAL FileShareCred;
Unmap it from any logins first (ALTER LOGIN ... DROP CREDENTIAL ...). Dropping a credential that a proxy uses leaves the proxy unusable, so repoint or delete the proxy as well.
Troubleshooting
A job step fails with a logon failure or "unknown user name or bad password". The secret is wrong or the account's password has changed or expired. Run ALTER CREDENTIAL with the current password. Service accounts with non-expiring passwords, or group managed service accounts for the services themselves, avoid the recurring version of this problem.
Backup to URL cannot open the backup device. Check, in this order: the credential name matches the container URL exactly with no trailing slash, IDENTITY is exactly SHARED ACCESS SIGNATURE, the token has no leading ?, and the token has not expired and grants at least read, write and list on the container.
The proxy does not appear in the job step's Run as list. The proxy has not been granted to that step's subsystem, or it is disabled.
A non-sysadmin cannot select the proxy. Grant the login access with sp_grant_login_to_proxy.
Access is denied on the file share even though the credential is correct. The job step is still running as the Agent service account. Set Run as on the step; creating the proxy does not change existing steps.
Credentials stop working after master is restored on another server. Secrets are encrypted with the service master key of the original instance. Restore that key, or recreate the credentials.
Security notes
Scripts that contain CREATE CREDENTIAL contain the secret in plain text. Keep them out of source control and shared folders, and pass the secret in at deployment time.
Give SAS tokens an expiry date and plan the rotation; an expired token is the most common reason a cloud backup job suddenly fails.
Review sys.credentials and msdb.dbo.sysproxies when people or systems leave. Credentials for accounts that no longer exist are harmless, but ones for live accounts that nobody remembers are not.
A query-first method: find the expensive queries, read the plan for signs the missing index DMVs never report, build the index online safely, then verify and roll back.
