How should security teams harden an IIS site so only approved users can access it?

Start by disabling Anonymous Authentication, then enable Windows Authentication and tighten site permissions so only the intended groups retain read access. Remove broad principals such as Everyone, Authenticated Users, and Users unless they are explicitly required. This approach reduces accidental exposure and keeps access aligned to least privilege. Use the site’s permission inheritance carefully so you do not break system access while hardening the application.

How IIS Access Control Actually Works

Hardening an IIS site starts with the two layers that govern who can reach content: authentication at the site level and file-system permissions underneath it. Disabling Anonymous Authentication forces IIS to identify users before serving the site, while Windows Authentication lets you rely on existing domain groups and access policies instead of standing up a separate account model. The goal is not just to “turn on auth,” but to make the approved user set explicit and auditable.

IIS permission inheritance matters because access can be granted both in the site configuration and in the NTFS ACLs on the content root. If the directory still allows broad read access, a locked-down IIS authentication setting may not be enough to prevent exposure. The cleanest pattern is to align the site’s identity requirements with the folder’s effective permissions so the web server and the operating system enforce the same decision.

For most environments, that means using domain groups for access rather than individual users, then confirming that only those groups have the minimum read permission needed for the application to function. Where a site serves multiple audiences, separate the content paths or applications so one permission set does not accidentally broaden another. This is the practical difference between “hardened” and merely “less exposed.”

Which Accounts and Permissions Should Be Removed?

The first cleanup step is to remove broad principals such as Everyone, Authenticated Users, and Users unless the site genuinely depends on them. Those entries often survive from default installation settings or inherited folder ACLs, but they make it easy for access to expand silently over time. If a broad principal is present, treat it as a design choice that needs justification, not as a harmless default.

Approved access should usually be expressed through a small set of named security groups that map to business roles. That keeps the access model legible for administrators and easier to review when the site changes ownership or when staff move between teams. It also reduces the chance that a single overly permissive group membership opens the site to a wider population than intended.

When tightening permissions, check both the visible IIS authentication settings and the effective ACLs on the application root, configuration files, and any subdirectories that contain sensitive content. Inherited permissions can reintroduce access from parent folders, and application pools may still need service rights even when end-user read access is restricted. The hardening job is complete only when the effective access path matches the intended one end to end.

What Good Hardening Looks Like in Practice

Good IIS hardening produces a simple and testable access model: unauthenticated users are blocked, approved users can authenticate successfully, and unapproved users are denied even if they can reach the web server. That means validating not only the configuration, but also the actual experience from a non-member account and from a user outside the approved groups. The test should confirm both login behavior and content retrieval behavior.

For a site that relies on Windows Authentication, use domain group membership as the control point and keep the group list small enough to review without guesswork. If the application has multiple roles, separate read-only access from administrative access instead of relying on one broad group with hidden exceptions. If you need to preserve system function, grant service accounts only the specific rights they require and nothing broader.

Document the resulting access model so future changes do not undo the hardening effort. In practice, that means recording which groups are allowed, which folders inherit permissions, and which exceptions exist for operational needs. IAM and IGA Basics is a useful foundation when you want to keep those approvals and entitlements aligned over time.

Risk and Threat Considerations

Overly broad IIS access most often fails through accidental exposure, not dramatic compromise. A misapplied inherited ACL, an unchanged default group, or a forgotten anonymous setting can expose content to users who were never meant to see it. In more regulated environments, that same weakness can create audit findings because access is no longer limited to an approved business need.

Failure mechanism: The site trusts a broad principal, or the file-system ACL overrides the intended IIS access policy, so the server serves content to a larger user population than the application owner expects. Attackers and internal users alike can exploit that gap by using any valid account that still falls within the overly permissive access rule.

Impact: Sensitive content can be disclosed, internal-only functions can become reachable, and unauthorized users may gain a path to data they should not see. If administrative or staging content is exposed, the issue can escalate from simple confidentiality loss to tampering, privilege misuse, or broader application compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Restricts IIS and folder access to the minimum approved users.
	AC-3 — Access Enforcement	IIS must enforce the site's approved-user access decision at the system boundary.
Recommendation — Apply AC-6 to remove broad principals and scope access to the smallest approved groups. Use AC-3 to enforce authentication-backed access decisions on the site and content paths.
ISO/IEC 27001:2022	A.5.15 — Access control	Maps to controlling who may access the IIS site and its content.
Recommendation — Implement A.5.15 to define and enforce approved-user access rules for the IIS application.
CIS Controls v8	CIS-6 — Access Control Management	Covers removing broad access and managing permissions on the web application.
Recommendation — Use CIS-6 to review, limit, and revoke unnecessary IIS access.
OWASP ASVS	V8 — Authorization	Authorization governs which authenticated users may reach protected web content.
Recommendation — Apply V8 to verify only authorized users can access protected IIS functionality.

Practitioner Guidance

What to verify: Confirm the effective permissions on the site root, the web.config path, and any child directories that serve content. Test with one approved account and one clearly unapproved account, because a configuration that looks correct in the console can still inherit access from the file system.

Common mistake: Treating IIS authentication as the only control. Access hardening is only reliable when the authentication choice, the group membership model, and the NTFS permissions all point to the same approved user set.

Decision rule: If a principal is not required for the site to function, remove it; if it is required, scope it to the smallest group or service identity that satisfies the application. When in doubt, prefer explicit group-based access over inherited broad access because it is easier to review and revoke.

Practitioner takeaway: Harden IIS by making access decisions explicit at both layers, then prove that only the intended users can read the content in practice, not just in configuration.