Your IIS server is still negotiating TLS 1.1. When was that last reviewed?
IIS does not configure TLS through a config file. It uses registry keys under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. These keys are rarely documented, rarely checked, and often never explicitly set. No browser breaks, no error message appears, but the PCI-DSS auditor or NIS2 assessor will find it.
What auditors find in standard IIS environments
These vulnerabilities show up in PCI-DSS and NIS2 audits on a regular basis. None of them require an exploit. It is enough that nobody has touched the TLS configuration in the past three years.
SchChannel registry keys for TLS 1.0 and TLS 1.1 are not set to disabled. Connections succeed. No browser error. PCI-DSS requires a minimum of TLS 1.2.
RC4, 3DES, and NULL ciphers are not disabled in the Windows default configuration. Cipher suite ordering via GPO or registry is absent in most environments.
X-Powered-By: ASP.NET and Server: Microsoft-IIS/10.0 appear in every HTTP response by default. Version disclosure is a standalone audit finding.
X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, and Content-Security-Policy are absent from the IIS default configuration. None are set automatically.
Multiple applications running under the same app pool identity or service account. A compromised application directory has access to all others sharing that account.
HTTP methods such as TRACE and CONNECT are not restricted. URL lengths, file extensions, and double-encoded requests are not filtered.
Directory browsing is active by default in many IIS instances and was never explicitly disabled. Directory listings are not a feature that should be exposed.
HTTP TRACE is active by default and enables Cross-Site Tracing attacks. A single web.config entry or request filter closes this. It is rarely set.
Why IIS is different from Apache or Nginx
The critical difference is not in the feature set. It is in the configuration model for TLS. This is exactly why legacy protocols remain active and undetected for years.
TLS protocols and cipher suites live in a text file. A package update can set safer defaults. Changes are diffable, versionable in Git, and the configuration state is readable without system access.
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite HIGH:!RC4:!3DES:!NULL
TLS configuration lives in the SchChannel registry hive. No package update sets these keys automatically. Not setting them explicitly means legacy protocols remain active. The state is only readable from the registry, not from logs or config files.
HKLM\...\SCHANNEL\Protocols\TLS 1.0\Server Enabled = 0x00000000 DisabledByDefault = 0x00000001
The same pattern applies to cipher suite ordering (GPO or registry), security headers (web.config or IIS Manager), and app pool identities (IIS configuration, not an OS package). Everything is IIS-specific, everything must be set explicitly, and nothing comes from an update.
What this module will address
Four technical areas that are consistently open in grown IIS environments and that this module will cover as an automated, documented target state.
TLS and Cipher Hardening
SchChannel registry keys for TLS 1.0, 1.1, 1.2, and 1.3 explicitly configured. Cipher suite ordering set via GPO or registry. RC4, 3DES, and NULL ciphers disabled. Documented configuration state as evidence for PCI-DSS TLS minimum requirements.
Security Headers via web.config
Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy as a versioned web.config standard. Server version removed from response headers. Consistent across all IIS sites, no manual per-instance intervention.
App Pool Isolation
Each application gets a dedicated app pool identity. Access separation enforced at OS level. App pool configuration as a versioned target state, not as a manually grown structure with no visibility into permissions and dependencies.
Request Filtering and HTTP Methods
Allowed HTTP methods restricted to GET, POST, and HEAD. TRACE blocked. URL lengths bounded. File extensions filtered. Directory browsing disabled. Request filtering as a declarative configuration state with compliance evidence.
IIS hardening requires OS hardening
IIS is not a standalone platform. It runs on Windows, is configured through Windows mechanisms (registry, GPO, Active Directory), and its security depends directly on the underlying OS foundation.
A carefully configured IIS on a neglected Windows Server closes only part of the attack surface. Outdated Windows versions, missing OS hardening, and GPO sprawl undermine IIS-specific controls at the system level. OS hardening and IIS hardening are deployed as a single automation logic, not as separate silos.
Secure Windows Platform Automation
The corresponding module for the OS layer. CIS Windows Benchmark baselines, Ansible for Windows, lifecycle management. IIS hardening and OS hardening are deployed together, not in isolation.
When this module becomes relevant
PCI-DSS audit reveals TLS problem
The assessor finds TLS 1.0 or 1.1 active. Nobody knows for how long. No config file to check, no diff history. SchChannel registry keys were never explicitly set. The follow-up question is how many other IIS instances in the organization are in the same state.
Security headers absent from the default configuration
No HSTS, no Content-Security-Policy, no X-Frame-Options. Every new IIS instance starts without these headers because no organizational target state for web.config configuration exists. Every instance is a deviation.
App pool sprawl with one service account for everything
Five applications, one app pool, one identity. Applications that should be processing separate data share the same account. Isolation is not implemented because no process exists for it and nobody has an overview.
What is possible today, what is in development
IIS hardening through Engineering as a Service
SchChannel configuration, security headers, app pool isolation, request filtering: this is actionable implementation work, not a product release gate. IIS hardening projects are delivered today through Engineering as a Service (EaaS).
Platform Check (15 min.)Automated IIS module as part of SPAS
Automated assessment of SchChannel configuration state, cipher suite analysis, app pool isolation report, security header compliance evidence. As a reproducible module with a versioned target state, not as a one-time audit.
IIS in scope of an audit? We can quickly assess what is actually configured in SchChannel and web.config.
No commitment · No sales pitch · Confidential
