Limit Server Application User Privileges
Server apps must run separately with only the necessary permissions to operate.
Plain language
This control is about making sure that any software running on your server doesn't have more power than it needs. If an application has too many permissions, a hacker could exploit these and cause damage or access sensitive information. By keeping permissions to the bare minimum, we limit what harm can be done if there's a breach.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Nov 2024
Control Stack last updated
18 May 2026
E8 maturity levels
N/A
Guideline
Guidelines for system hardeningSection
Server application hardeningOfficial control statement
Server applications are configured to run as a separate user account with the minimum privileges needed to perform their functions.
Why it matters
If server apps run with excessive privileges or shared accounts, an attacker can escalate access, alter data, or disrupt services.
Operational notes
Run each server application under its own dedicated account; review granted rights and group memberships regularly and remove any no longer required.
Implementation tips
- System owners should create a separate user account for each server application. This means asking your IT team to set up a specific account that is used only by that application. It should have the lowest level of access to get its job done-nothing more.
- The IT team should review each application’s functions to determine necessary permissions. They need to document what the application actually needs to do, and configure the server accordingly, ensuring it can’t access other data or functions.
- Managers should schedule regular meetings with the IT team to review application user accounts. These meetings can ensure that no extra permissions have been added over time and uphold the security processes you've put in place.
- Procurement should ensure any new software clearly states its permission needs before purchase. This prevents buying applications that demand excessive access, keeping your systems secure from the start.
- The IT team should monitor server logs for unusual activities by application accounts. They should use these logs to spot if an application suddenly starts doing more than it should, which might indicate an account has been compromised.
Audit / evidence tips
- AskUser account documentation: Request a list of all user accounts associated with server applications GoodList clearly separates application accounts from regular user accounts with defined roles
- AskA permissions review report: Request a document that shows the permissions each application has
- AskMeeting notes from IT reviews: Request documentation of the regular meetings held to discuss application permissions
- AskLogs showing account activity: Request server logs that show what application accounts have done recently
- AskProcurement records of new software: Request records of software evaluations pre-purchase
Cross-framework mappings
How ISM-1249 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (2) expand_less | ||
| Annex A 8.2 | ISM-1249 requires server applications to use separate user accounts and least privilege to perform their functions | |
| Annex A 8.3 | ISM-1249 requires that server applications run under separate accounts with only the permissions they need | |
E8
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| E8-RA-ML3.1 | ISM-1249 requires server applications to run under separate user accounts with only the minimum privileges required for their function | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.