SharePoint Server Security Guide: Farm Accounts, Machine Keys, AMSI and Patching On-Premises

On-premises SharePoint Server farms are internet-facing .NET applications that run with domain service accounts, SQL Server rights and shared ASP.NET machine keys, and the 2025 ToolShell campaign showed that patching alone does not evict an attacker who has stolen those keys. The farm's security depends on a handful of non-human identities: the farm service account, application pool accounts, the search crawl account, the user profile synchronisation account and the machine keys that sign ViewState. This guide covers how identity and access work in a SharePoint Server farm, which accounts are privileged, how to log and detect abuse, and the hardening and patching baseline for SharePoint Server 2016, 2019 and Subscription Edition. It is for SharePoint administrators, Windows and SQL Server engineers and security teams. SharePoint in Microsoft 365 is covered separately in the SharePoint and OneDrive Security Guide.

Key takeaways

• Machine keys are credentials. The ASP.NET ValidationKey and DecryptionKey let anyone who holds them forge trusted ViewState, so rotate them with Set-SPMachineKey or the Machine Key Rotation Job after any suspected compromise, and again after patching.
• The farm service account is close to Tier 0. It runs Central Administration and the Timer Service, holds dbcreator and securityadmin on SQL Server and db_owner on every SharePoint database; Microsoft treats securityadmin as equivalent to sysadmin.
• Versions matter now. Microsoft lists the extended support end date for SharePoint Server 2016 and 2019 as 15 July 2026 (06:59 Pacific time), so farms still on those versions no longer get standard security updates.
• AMSI is your pre-patch shield. AMSI integration scans incoming requests before SharePoint processes them, and from the September 2025 public update it is mandatory on 2016, 2019 and Subscription Edition; Subscription Edition 25H1 and later can also scan request bodies.
• Assume compromise means rotating everything. After a web shell, rotate machine keys, service account passwords, connection strings and certificates, not just the patch level.

How identity and access work in SharePoint Server

A SharePoint Server farm is a set of Windows servers running IIS web applications, service applications and timer jobs, all sharing one configuration database on SQL Server. Users authenticate to web applications through Windows authentication (NTLM or Kerberos), SAML claims from a trusted identity provider such as AD FS, or forms-based authentication, and SharePoint converts every login into a claims identity. Site permissions then come from SharePoint groups and permission levels inside each site collection.

Behind the user layer, the farm itself authenticates to SQL Server, Active Directory and other systems using service identities configured as managed accounts. Those are the identities attackers want, because they are shared by every web front end.

Admin roles and privileged access

• Farm Administrators group: full control of the farm through Central Administration. Microsoft recommends a separate, personally identifiable account per administrator, grouped through a security group, rather than shared admin accounts.
• Shell administrators: Add-SPShellAdmin grants the SharePoint_Shell_Access role on the configuration database and chosen content databases, which carries execute on all stored procedures and read and write on all tables. Treat it as farm administration, because it is.
• SQL Server roles: Microsoft's least-privilege guidance says to keep dbcreator and securityadmin only on the account running the Workflow Timer Service (normally the farm service account), that no SharePoint service account should hold sysadmin or be a local administrator on the SQL Server, and that securityadmin should be treated like sysadmin. Removing these roles from the farm account breaks provisioning, restores and upgrades, so plan a temporary elevation process instead.
• Local groups: WSS_ADMIN_WPG has read and write on SharePoint registry keys and data folders; WSS_RESTRICTED_WPG can read the encrypted farm administration credential key (Secure\FarmAdmin). Membership of either should be limited to the accounts SharePoint itself adds. Since the September 2025 update, members of WSS_WPG are blocked from running administrative processes.
• Interactive logon: Microsoft says service application pool accounts (except C2WTS) should have Deny log on locally and Deny log on through Remote Desktop Services. Apply the same to web application pool and crawl accounts.
• Site collection administrators: can change permissions and, on older configurations, upload custom code. Review them per site collection, especially on publishing and intranet portals.
• Admin workstations: run Central Administration only from privileged access workstations and never expose it to the internet. See the Tiered Administration and Enterprise Access Model Guide.

Integrations, API tokens and service accounts

• Use managed accounts and gMSAs where supported: register service accounts as SharePoint managed accounts so passwords can be changed centrally and, where your version and services allow, use automatic password change. Microsoft notes that service account names should not contain $ except for a gMSA used with SQL Server. See the Windows Services and Service Account Security Guide.
• Scope the crawl account: the default content access account reads everything it indexes. Use crawl rules with separate content access accounts for sensitive sources, and never make the crawl account a farm administrator.
• Keep profile synchronisation narrow: the AD import account needs Replicate Directory Changes only. Check it has not been granted Replicating Directory Changes All, which would let it perform DCSync (T1003.006). See the Golden Ticket, Silver Ticket and DCSync Guide.
• Enable C2WTS only when needed: Excel Services, PerformancePoint or Kerberos constrained delegation scenarios may require it. When enabled, run it as a separate account and constrain delegation targets. See the Kerberos Delegation Security Guide.
• Treat high-trust add-ins and server-to-server trusts as key material: provider-hosted add-ins and workflow connections rely on signing certificates trusted by the farm. Inventory each trusted token issuer and certificate (Get-SPTrustedSecurityTokenIssuer, Get-SPTrustedIdentityTokenIssuer), record owners and expiry, and remove unused ones.
• SAML trusts: when AD FS or another IdP signs tokens for SharePoint, the token-signing certificate is a farm-wide credential. See the AD FS Security Guide.
• Secrets on disk: web.config files hold machine keys and sometimes connection strings for custom solutions (T1552.001 Credentials In Files). Restrict who can read the IIS virtual directory folders and back them up securely.

Logging and detection

CISA's ToolShell advisory also notes that malicious modules can be registered in applicationHost.config and web.config, so include those files in configuration drift monitoring. The Web Server Access Log Detection Guide and the Web Shell Response Playbook cover the detection and response side.

Metrics

• Patch latency: days from a SharePoint security update to all farm servers patched and the Products Configuration Wizard run (target within your critical window, days not weeks, for KEV-listed flaws).
• AMSI coverage: percentage of web applications with AMSI active, and on Subscription Edition the request body scan mode (Balanced or Full).
• Privileged accounts: count of farm administrators, shell administrators and accounts with securityadmin or sysadmin, reviewed monthly.
• Machine key age: days since last rotation per web application, and rotation within 24 hours of any web shell finding.
• Interactive logons by service accounts: target zero.
• Unsupported servers: number of farm servers on versions past their extended end date.

Hardening baseline

Patching and version strategy

CISA's Known Exploited Vulnerabilities catalogue lists many SharePoint flaws, including CVE-2025-53770 (deserialisation), CVE-2025-49704 (code injection) and CVE-2025-49706 (improper authentication) from the ToolShell chain, CVE-2023-29357 (privilege escalation) and further SharePoint entries added through 2026. Every SharePoint update requires the binaries on every server and then the SharePoint Products Configuration Wizard (or PSConfig) to complete database upgrades, and 2016 and 2019 updates for ToolShell also required the language pack update. Track the cumulative update level of each farm and test in a staging farm before production. See the Patch Management Guide.

Rollout steps

1. Inventory the farm: servers and roles, web applications and their authentication providers, managed accounts, farm and shell administrators, SQL roles, trusted token issuers and internet exposure.
2. Reduce exposure: publish SharePoint externally only through an authenticated reverse proxy, VPN or gateway; block /_admin and Central Administration ports from untrusted networks; put WAF rules in front of /_layouts/ endpoints.
3. Confirm AMSI: verify the SharePoint Server Antimalware Scanning feature is active on each web application (Enable-SPFeature with feature ID 4cf046f3-38c7-495f-a7da-a1292d32e8e9) and test with the AMSI test string from Microsoft's documentation, which Defender reports as Exploit:Script/SharePointEicar.A. On Subscription Edition 25H1 and later, start with Balanced body scanning and move to Full after a performance pilot.
4. Separate accounts: distinct accounts for setup, farm service, web application pools, service application pools, crawl and profile sync; deny interactive and RDP logon to all service identities; remove any from Domain Admins or local Administrators beyond what Microsoft documents.
5. Rotate machine keys on a schedule: run Set-SPMachineKey or the Machine Key Rotation Job in Central Administration (Monitoring, Review job definitions), then iisreset.exe on every server. Rotate after every incident and after major patches. Test in staging first, because active sessions and forms tokens become invalid.
6. Harden the hosts: apply your IIS and Windows baselines, enable LSA protection and Credential Guard, and deploy EDR in block mode. See the IIS Hardening Guide.
7. Plan rollback: back up the configuration and content databases and take server snapshots before updates; for machine key rotation, the rollback is to re-run rotation, not to restore old keys that may be compromised.

Decision guidance

• Stay on-premises or move: keep a farm on-premises when data residency, custom full-trust code or disconnected networks require it; otherwise moving content to SharePoint in Microsoft 365 removes machine key, patching and farm account risk from your scope, at the cost of different SaaS controls.
• Small farms: a single-server or three-server farm still needs separate farm and app pool accounts and AMSI; skip least-privilege SQL changes that Microsoft says increase operational cost and use monitoring instead.
• Large or high-security farms: apply Microsoft's least-privileged administration guidance (restricted SQL roles, DBA separation, C2WTS off), with a documented temporary elevation process for upgrades.

Common misconfigurations

• Patching without rotating keys: in the ToolShell SharePoint exploitation, attackers used spinstall0.aspx to read the ValidationKey and DecryptionKey, so patched servers stayed exploitable until keys were rotated and IIS restarted.
• One account for everything: the farm service account also runs web application pools and the crawler, so a web exploit lands directly in an identity with db_owner on every database.
• Central Administration reachable from the internet: or from the general user network, exposing the most privileged web application.
• AMSI deactivated for performance: earlier versions let administrators switch it off per web application, which removed the only protection during the ToolShell zero-day window.
• Out-of-support farms left online: 2013 and now 2016 and 2019 farms kept running because migration is hard, with no security updates for new flaws.
• Over-granted sync account: the profile import account given Replicating Directory Changes All "to make it work", creating a DCSync-capable credential on a web server.

Framework mapping

Practitioner checklist

• Confirm every farm server's version and patch level, and plan migration for any 2016, 2019 or older farm.
• Verify AMSI is active on every web application and test it with the documented test string.
• Rotate ASP.NET machine keys on all web applications and restart IIS on every server; schedule regular rotation.
• Separate setup, farm, app pool, crawl and sync accounts, and deny interactive and RDP logon for service identities.
• Remove sysadmin and local SQL administrator rights from SharePoint accounts and list who holds securityadmin.
• Review Farm Administrators, shell administrators and site collection administrators.
• Check the profile sync account holds Replicate Directory Changes only.
• Block Central Administration and /_layouts/ exploit paths from untrusted networks and publish through an authenticated gateway.
• Monitor w3wp.exe child processes, new .aspx files in layouts folders and changes to web.config and applicationHost.config.
• Prepare an incident runbook that rotates machine keys, service account passwords, connection strings and certificates together.

Standards and references

• Microsoft Learn: Account permissions and security settings in SharePoint Server
• Microsoft Learn: Plan for least-privileged administration in SharePoint Server
• Microsoft Learn: Configure AMSI integration with SharePoint Server
• Microsoft Security Blog: Disrupting active exploitation of on-premises SharePoint vulnerabilities
• CISA: Microsoft releases guidance on exploitation of SharePoint vulnerabilities
• CISA: Known Exploited Vulnerabilities Catalog
• Microsoft Lifecycle: SharePoint Server 2019
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: SharePoint and OneDrive Security Guide · Service Account Security Guide · Insecure Deserialisation Guide · Web Shell Response Playbook