Your Admin Accounts

Every catastrophic breach you’ve ever read about ended the same way: the attacker got admin access. Initial compromise is usually mundane — a phished credential, a misconfigured service, a vulnerable web application. But the escalation from foothold to total compromise runs through privileged accounts every time. Domain admin. Root. Cloud IAM owner. Database admin. These accounts can read everything, change everything, delete everything, and cover the tracks.

If you manage infrastructure, cloud environments, or anything with admin-level access, this guide is the hardening checklist. Not the theory — the specific controls, tools, and procedures that make privileged accounts orders of magnitude harder to abuse.

DO / DON’T

DO:

• Use separate accounts for daily work and administrative tasks
• Vault all privileged credentials in a dedicated secrets manager
• Implement just-in-time (JIT) access for admin privileges
• Record and monitor all privileged sessions
• Rotate privileged credentials on a schedule and after every use
• Maintain documented break-glass procedures for emergency access
• Inventory every service account and treat them as privileged

DON’T:

• Use your admin account to read email, browse the web, or do daily tasks
• Store admin passwords in personal password managers, spreadsheets, or your head
• Grant standing admin access when temporary access would suffice
• Share admin credentials via chat, email, or sticky notes — ever
• Exempt service accounts from credential rotation and monitoring
• Wait until an incident to figure out your break-glass procedure
• Assume MFA on an admin account is sufficient without additional PAM controls

Separate Your Accounts

This is the foundational control that everything else builds on. If you do nothing else from this guide, do this.

The Two-Account Model

Every person who needs admin access operates with two accounts:

1. Daily-use account: Email, Slack, browsing, documents, meetings. Standard permissions. This account is exposed to phishing, malware, and all the threats that come with normal computer use.
2. Admin account: Used exclusively for administrative tasks. Never opens email. Never browses the web. Ideally used only from a dedicated admin workstation or a hardened jump box.

The principle: your admin credentials should never touch a system where they could be harvested by an attacker who compromised your daily workflow. Microsoft’s tiered access model formalizes this — Tier 0 credentials (domain admins) only authenticate to Tier 0 systems (domain controllers). They never touch Tier 1 (servers) or Tier 2 (workstations).

Privileged Access Workstations (PAWs)

For maximum isolation, admin tasks should be performed from dedicated workstations that are locked down to only administrative use:

• No email client. No web browser (except to admin consoles). No personal applications.
• Full disk encryption, application whitelisting, and enhanced monitoring.
• Network-segmented to only reach admin interfaces.

If dedicated hardware isn’t feasible, use a hardened virtual machine for admin tasks — booted fresh for each session, not persisted between uses.

Vault Your Credentials

No human should know a production admin password. No config file should contain a hardcoded credential. Every privileged credential belongs in a vault.

Setting Up Credential Vaulting

• Choose a vault: HashiCorp Vault (self-hosted or HCP Vault), CyberArk, AWS Secrets Manager, Azure Key Vault, or Delinea Secret Server. The right choice depends on your environment — cloud-native organizations often start with their cloud provider’s secrets manager; hybrid environments benefit from dedicated PAM platforms.
• Migrate credentials into the vault. Start with the highest-privilege accounts: domain admin, root, cloud owner accounts. Then service accounts. Then database admin credentials.
• Enable automatic rotation. Configure the vault to rotate each credential on a schedule (every 30-90 days) and after every checkout. When an admin checks a credential back in, the vault changes the password so the checked-out value is immediately useless.
• Enforce checkout workflows. Require a reason for checkout. Require approval for the most sensitive credentials. Set maximum checkout durations. Log everything.

Service Account Credentials

Service accounts are the hidden minefield. They outnumber human accounts in most environments, use static passwords, and often have excessive privileges.

• Inventory every service account. You cannot secure what you don’t know exists. Audit Active Directory, cloud IAM, database users, and application configurations.
• Move service account credentials into the vault. Configure applications to retrieve credentials from the vault at runtime via API, rather than storing them in config files.
• Rotate service account passwords automatically. The vault handles the rotation and propagates the new credential to the application. No human intervention needed. No stale passwords sitting in config files for years.
• Eliminate shared service accounts. Each application or workflow should have its own service account with permissions scoped to exactly what it needs — NIST SP 800-53 AC-6 (Least Privilege).

Implement Just-in-Time Access

The gold standard: nobody has standing admin privileges. Admin access is requested, approved, time-limited, and automatically revoked.

How to Deploy JIT

• Azure AD/Entra ID: Privileged Identity Management (PIM) provides JIT for Azure AD roles and Azure resource roles. Eligible assignments mean the person can activate the role when needed; active assignments are standing — convert everything to eligible.
• AWS: IAM Identity Center with temporary elevated access, or implement JIT via AWS SSO permission sets with time-limited sessions.
• CyberArk / BeyondTrust / Delinea: Enterprise PAM platforms provide JIT natively — define approval workflows, time windows, and automatic revocation.

JIT Policies to Set

• Maximum elevation duration: 1-4 hours for routine admin tasks. Require re-request for longer durations.
• Require justification: Every request should include a ticket number, change request, or written reason. This creates an audit trail.
• Approval workflow: Auto-approve for low-risk elevations (reading logs). Require manager or peer approval for high-risk elevations (modifying security configurations, accessing production data).
• Notifications: Alert security teams when admin privileges are activated, especially outside business hours.

Monitor Privileged Sessions

When someone is operating with admin-level access, record what they do. Every command, every query, every configuration change.

What to Record

• Terminal sessions on servers and network devices. Tools: CyberArk PSM, BeyondTrust, Teleport, or native session recording (script command on Linux, Windows Event Forwarding for PowerShell).
• RDP sessions to Windows servers. CyberArk and BeyondTrust can record and play back full RDP sessions.
• Database queries executed under admin credentials. Enable database audit logging (SQL Server Audit, PostgreSQL pgAudit, MySQL Enterprise Audit).
• Cloud console actions performed under elevated IAM roles. Cloud audit logs (CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) capture these automatically — make sure they’re enabled in all regions.

What to Alert On

• Commands that modify security configurations: iptables, setenforce, Set-MpPreference, IAM policy changes, security group modifications.
• Bulk data access: Large database exports, mass file downloads, or unusual data transfer volumes under an admin account.
• Off-hours admin activity: Admin privilege activation at 2 AM on a Saturday should trigger an immediate alert unless there’s a corresponding change window.
• Credential dumping indicators: Execution of known tools (Mimikatz, ProcDump targeting LSASS, ntdsutil) — MITRE ATT&CK T1003 (OS Credential Dumping).

Break-Glass Procedures

When your PAM system is down, your IdP is unreachable, or you’re locked out of your cloud console during an active incident, you need a way in. That’s the break-glass procedure. Build it before you need it.

Setting It Up

• Create break-glass accounts: One or two emergency admin accounts with the highest privilege level. Configure them with FIDO2 hardware keys (two per account — primary and backup).
• Document the procedure: Step-by-step instructions for accessing break-glass credentials — where the hardware keys are physically stored, what systems the accounts access, what the initial recovery steps are.
• Store credentials securely: Hardware keys in a physical safe. Account passwords printed and sealed in tamper-evident envelopes in a separate safe. Not in a password manager — the password manager might be the thing that’s down.
• Test quarterly: Actually log in with the break-glass accounts. Verify they work. Verify the hardware keys work. Verify the documented procedure is accurate. Reset credentials after each test.
• Alert on break-glass usage: Any login to a break-glass account should trigger an immediate high-priority alert to the security team. If nobody initiated a break-glass, it’s an incident.

NIST SP 800-53 AC-2(2) requires removal of temporary/emergency accounts after defined periods. Break-glass accounts are the exception — they persist but are heavily monitored.

If It Already Happened

If you suspect a privileged account has been compromised:

1. Disable the account immediately. Don’t change the password — disable it. A password change leaves active sessions intact.
2. Revoke all active sessions and tokens from the compromised account across every system it had access to.
3. Rotate every credential the account had access to. If the compromised account could access the credential vault, rotate everything in the vault. If it had access to service account passwords, rotate those. Assume the attacker extracted everything they could reach.
4. Check for persistence. Look for new accounts, modified group memberships, scheduled tasks, cron jobs, SSH keys, OAuth applications, and any other persistence mechanism — MITRE ATT&CK Persistence tactics catalog the techniques.
5. Review session recordings and audit logs. Reconstruct exactly what the compromised account did. Every command, every access, every change. This determines the blast radius.
6. Isolate affected systems if the scope of compromise is unclear. It’s better to take systems offline temporarily than to leave an attacker with continued access.
7. Engage incident response. A compromised admin account is a critical-severity incident. Activate your incident response plan and bring in your security team or a third-party IR firm.

The theme across all of these controls is the same: make privileged access hard to get, hard to keep, hard to misuse, and impossible to hide. Every control you implement from this list raises the cost for an attacker. Stack enough of them and the cost becomes prohibitive.