Service Account
Decision Framework
A structured methodology for IT teams to select, configure, and document the correct service account type for new application deployments — balancing security posture against operational complexity.
Account Types at a Glance
Group Managed Service Account
gMSA
The gold standard for multi-server deployments. AD manages password rotation automatically every 30 days with no downtime. Requires Server 2012+ and KDS Root Key.
Standalone Managed Service Account
sMSA
Per-host managed service account. Same auto-rotation benefits as gMSA but locked to a single computer object. Ideal for single-server services.
Standard Domain Service Account
Standard SA
Traditional domain user account repurposed as a service identity. Full flexibility but requires manual password management and carries elevated risk if not tightly controlled.
Local / Virtual Service Account
Local / Virtual
Built-in OS accounts (Local System, Network Service, Virtual Accounts) that require zero configuration. Best for services with no network identity requirements.
When to Use This Framework
Trigger Condition: Use this decision framework any time a new application, scheduled task, Windows service, or automated process requires a dedicated identity to authenticate and operate. Do not reuse existing service accounts across applications.
Policy Reminder: Interactive logon rights for service accounts must be explicitly justified and approved. Service accounts should never be used for human logins unless absolutely required (e.g., legacy thick-client service brokers).
Security Risk: Standard domain service accounts with non-expiring passwords and broad permissions represent a significant lateral movement vector. Default to gMSA wherever technically feasible.
Interactive
Decision Tree
Answer each question about your deployment requirements to receive a tailored service account recommendation with rationale.
Progress
Q 0 / 5
Instructions: Each question narrows down the appropriate account type for your scenario. Answer based on the actual technical requirements of the service being deployed — not what might be convenient. If you're unsure about a requirement, choose the more restrictive option and consult your security team.
Q1
Access Pattern
Does this service or application require interactive logon capabilities (e.g., running desktop sessions, RDP, or interactive console access)?
Interactive logon means a human or automated process actively logs into a session. Most background services, scheduled tasks, and APIs do not require this. Windows services and IIS app pools, for example, run without interactive sessions.
Q2
Network Scope
Does the service need to access network resources — such as file shares, databases on remote servers, APIs authenticated via Kerberos/NTLM, or other domain resources?
A service only needs network identity if it communicates with resources outside its own host. A service that reads only local files and uses localhost DB connections, for example, can operate as a Local or Virtual Account with no domain footprint.
Q3
Password Management
Can this service tolerate automated password rotation (managed by Active Directory, typically every 30 days) without requiring manual intervention?
Managed Service Accounts (gMSA/sMSA) rotate passwords automatically — the service retrieves the current password from AD at runtime. If your application stores credentials in a config file or database connection string with no ability to dynamically retrieve them from AD, it cannot use managed accounts.
Q4
Infrastructure Scope
Will this service run across multiple servers or hosts (e.g., a web farm, cluster, or load-balanced deployment), or only on a single server?
gMSA supports multiple host computer objects, meaning the same account works seamlessly across all nodes. sMSA is bound to one computer object only. If you're deploying to 2 or more servers, you need gMSA — sMSA will not work across hosts.
Q5
AD Infrastructure
Is a KDS Root Key provisioned in your Active Directory domain, and are all target servers running Windows Server 2012 or later?
gMSA requires a KDS Root Key (created once per domain via
Add-KdsRootKey -EffectiveImmediately) and Server 2012+ on all hosts that will run the service. Without these prerequisites, you must fall back to sMSA (single host) or a standard service account.Standard Domain Service Account
Domain User Account (with service account controls)
Your service requires interactive logon, which is not supported by managed service accounts. You must use a Standard Domain Service Account configured with strict controls. This carries elevated risk and requires compensating controls: deny interactive logon at GPO level unless specifically needed, enable "Password never expires" only with compensating LAPS or PAM solution, and implement privileged access workstation (PAW) policy for any human-touch access.
Security Level
⚠ ELEVATED RISK
Password Mgmt
Manual / PAM
AD Required
Yes
Required compensating controls: Restrict logon rights via GPO. Mandate MFA if interactive. Integrate with PAM vault (e.g., CyberArk). Rotate password at minimum every 90 days. Enable audit logging on all logon events. Document explicit business justification for interactive access rights.
Local / Virtual Service Account
Built-in: Local System, Network Service, or Virtual Account
Since the service doesn't need network access, you have zero reason to introduce a domain account with associated Kerberos tickets and AD attack surface. Use a Virtual Account (NT SERVICE\ServiceName) if available, or Local Service / Local System. These require no AD provisioning, no password management, and are automatically scoped to the local machine only.
Security Level
✓ OPTIMAL
Password Mgmt
None Required
AD Required
No
Best practices: Prefer Virtual Accounts (NT SERVICE\...) over Local System where possible — they're scoped to the service and less powerful. If Local System is required, document the justification. Review local permissions granted to the account and apply least privilege. No domain credentials = significantly reduced credential theft risk.
Standard Domain Service Account
Domain User Account — Static Password Required
The application cannot support automated password rotation, which rules out gMSA and sMSA. You must use a Standard Domain Service Account with a managed static password. This is the highest-risk option and must be paired with a PAM (Privileged Access Management) solution or enforced rotation schedule. Treat this as a legacy pattern and plan migration to gMSA when the application permits.
Security Level
⚠ HIGH RISK
Password Mgmt
Manual / PAM
Rotation
90 Day Max
Mandatory controls for static password accounts: Store credential in PAM vault (CyberArk, HashiCorp Vault, or LAPS equivalent). Enforce 90-day max rotation. Enable "Sensitive account" flag in AD. Apply "Deny log on locally" and "Deny log on via RDP" GPO. Audit all authentication events. Log a gMSA migration ticket in your backlog.
Group Managed Service Account
gMSA — AD-Managed, Multi-Host, Auto-Rotating
gMSA is the optimal choice for your deployment. Active Directory manages password rotation automatically (every 30 days by default) with zero service disruption. The account can authenticate to domain resources via Kerberos, works seamlessly across all cluster nodes or load-balanced servers, and requires no password storage in config files or vaults.
Security Level
✓ BEST PRACTICE
Password Mgmt
Automatic (AD)
Multi-Host
Yes
Provisioning steps: (1) Verify KDS Root Key exists. (2) Create gMSA:
New-ADServiceAccount -Name svc-AppName -DNSHostName app.domain.com -PrincipalsAllowedToRetrieveManagedPassword "ServerGroup". (3) Install on each host: Install-ADServiceAccount. (4) Configure service to use account with no password field (AD handles it). (5) Test with Test-ADServiceAccount.Standalone Managed Service Account
sMSA — Single-Host, Auto-Rotating
sMSA is the right fit: your service runs on a single host, needs network access, supports auto-rotation, but gMSA prerequisites aren't fully met (or the multi-host capability isn't needed). sMSA delivers the same automatic password management benefits as gMSA but is bound to one computer object — perfect for single-server deployments on older infrastructure.
Security Level
✓ STRONG
Password Mgmt
Automatic (AD)
Multi-Host
No — single only
Provisioning steps: (1) Create sMSA:
New-ADServiceAccount -Name svc-AppName -RestrictToSingleComputer. (2) Link to host: Add-ADComputerServiceAccount -Identity HostName -ServiceAccount svc-AppName. (3) Install: Install-ADServiceAccount on the target server. (4) Configure service to log on as the MSA. Note: If you migrate to multi-server later, plan upgrade to gMSA.Standalone Managed Service Account
sMSA — Fallback for Single-Host Without Full gMSA Prereqs
Since the service runs on a single server and gMSA prerequisites aren't fully in place, sMSA is the best available option. It provides automatic password management tied to a single computer object without requiring a KDS Root Key. As you upgrade infrastructure, plan migration to gMSA for greater flexibility.
Security Level
✓ STRONG
Password Mgmt
Automatic (AD)
Multi-Host
Not Available
Migration path: Log a ticket to provision the KDS Root Key when infrastructure is upgraded. sMSA → gMSA migration requires creating a new gMSA and updating the service configuration — no in-place upgrade. Plan for a brief maintenance window when migrating. The AD permissions and SPNs from the sMSA can be transferred to the new gMSA.
Service Account
Type Comparison
Full feature matrix across all service account types to support architectural decisions and security reviews.
Capability Matrix
| Capability | gMSA | sMSA | Standard SA | Local System | Virtual SA |
|---|---|---|---|---|---|
| Auto password rotation | ✓ Yes | ✓ Yes | ✗ Manual | N/A | N/A |
| Multi-host support | ✓ Yes | ✗ Single host | ✓ Yes | ✗ Local only | ✗ Local only |
| Network / domain auth | ✓ Yes | ✓ Yes | ✓ Yes | ⚠ As computer | ✗ No |
| Interactive logon | ✗ No | ✗ No | ✓ Yes | ✗ No | ✗ No |
| AD object required | ✓ Yes | ✓ Yes | ✓ Yes | ✗ No | ✗ No |
| KDS Root Key needed | ✓ Required | ✗ Not needed | ✗ Not needed | ✗ Not needed | ✗ Not needed |
| Min OS: Domain Controller | ⚠ 2012+ | ⚠ 2008 R2+ | ✓ Any | ✓ Any | ⚠ Vista/2008+ |
| Kerberos SPN support | ✓ Yes | ✓ Yes | ✓ Yes | ⚠ Computer SPN | ✗ No |
| No credential storage needed | ✓ Yes | ✓ Yes | ✗ Password req. | ✓ Yes | ✓ Yes |
| Configurable permissions | ✓ Full AD | ✓ Full AD | ✓ Full AD | ✗ Limited | ⚠ Local only |
| Attack surface | ✓ Low | ✓ Low | ✗ High | ⚠ Medium | ✓ Very Low |
| Recommended for new deployments | ✓✓ Primary | ✓ Yes | ⚠ Legacy only | ⚠ Local only | ✓ Local svc |
Security Risk Ranking
Decision Principle: Always select the account type with the minimum necessary privilege and the maximum automated security. Move up the risk hierarchy only when a genuine technical requirement forces it — and document the justification.
Audit
Documentation
Complete this form to generate a standardized service account decision record for your change management and audit trail requirements.
Pre-Submission Checklist
✓
Decision Tree completed and recommendation reviewed
Use the Decision Tree module before completing this form
✓
Application owner / requestor identified and confirmed
Must have a named business owner for every service account
✓
Principle of least privilege applied to account permissions
Only grant permissions explicitly required for the service to function
✓
Password / rotation strategy confirmed with application team
For Standard SA: PAM vault confirmed; for gMSA/sMSA: KDS key and AD prereqs verified
✓
Security team sign-off obtained (required for Standard SA and any interactive logon)
gMSA/sMSA/Local accounts require team lead approval only
✓
Change record / ITSM ticket created for account provisioning
Link the change record number in the form below
Decision Record Form
SERVICE ACCOUNT DECISION RECORD — v2.1
Section A — Identification
Application / Service Name
Account Name (SAM)
Environment
Requestor Name
Application Owner
Change Record Number
Date of Decision
Section B — Decision
Selected Account Type
Interactive Logon Required?
Network Resource Access?
Password Rotation Method
Decision Rationale
Section C — Controls & Review
Compensating Controls Applied
Next Review Date
Approver Name + Role
Migration Plan (if Standard SA)
Retention Policy: Service account decision records must be retained for a minimum of 3 years (or the lifetime of the account + 1 year, whichever is longer) to satisfy SOC 2, ISO 27001, and internal IT audit requirements. Store completed records in your ITSM system linked to the change record.