DBAs should never run SSMS under their everyday Windows account
If you open SSMS under the same Windows identity you use for email, browsing, and chat, you bring all that risk into your DBA tools. A single slip—phishing email, malicious link, infected USB stick —can let an attacker reuse your current login token and become you inside SQL Server. Switching to a separate admin identity makes that token reuse far harder.
Why this matters (short version)
Phishing & links. One click can execute code in your user context.
USBs & attachments. Malware runs as you and inherits your network access.
Token theft. Attackers can lift your Kerberos/NTLM tokens from processes and laterally move into SQL, file shares, and AD.
Bigger blast radius. If your daily user is mapped to powerful SQL roles (or sysadmin), compromise = instant production impact.
What to do instead
Separate identities. Use a hardened DBA/admin account for SSMS only; keep email/web on your normal account.
Run SSMS as a different user (see how-to below).
Least privilege in SQL. Use minimal rights, just-in-time (JIT) elevation when needed, and “break-glass” only with auditing.
MFA + conditional access. Protect the privileged account and restrict where it can sign in.
Ops discipline. Do DDL via CI/CD; auditing should be viewable by devs but not modifiable.
How to start SSMS as another account (Windows 10/11)
A) GUI: “Run as a different user”
Hold Shift, then right-click the SSMS shortcut (Start menu or taskbar).
Choose Run as a different user, and enter your
DOMAINDBA-accountcredentials.
B) GUI: “Run as administrator” (different from “different user,” but often needed on UAC-locked machines)
Right-click the SSMS link, then right-click the SSMS menu item and choose Run as administrator.
C) Command line (great for non-domain PCs connecting to domain SQL)
You’ll authenticate as that domain user for network access while SSMS still runs on your local machine. Update the path to match your SSMS version.
Become the Sysadmin DBA not the every day DBA!
Bottom line: Don’t hand attackers your keys by running SSMS as your daily Windows user. Launch it with a separate, locked-down account and keep your tokens—and your production estate—out of reach. You don’t want to be the reason ransomware finds its way down to your SQL Server instances.