NIST 800-53 Controls for Web Applications: What Actually Applies (2026)

What Is NIST 800-53?

NIST Special Publication 800-53 is the US federal government's catalog of security and privacy controls for information systems. Published by the National Institute of Standards and Technology, Revision 5 shipped in 2020 and expanded the catalog to 1,189 controls across 20 families.

It was built to satisfy FISMA, the Federal Information Security Modernization Act. FedRAMP then made it the de facto standard for any SaaS selling to US federal agencies, which pushed it far outside its original government scope. Most companies that target the Moderate baseline end up implementing around 325 controls. Not all 1,189.

The full catalog is free at csrc.nist.gov. SP 800-53B defines which controls belong to each baseline (Low, Moderate, High).

The 20 Control Families

Each family gets a two-letter code:

AC (Access Control), AT (Awareness and Training), AU (Audit and Accountability), CA (Assessment, Authorization, and Monitoring), CM (Configuration Management), CP (Contingency Planning), IA (Identification and Authentication), IR (Incident Response), MA (Maintenance), MP (Media Protection), PE (Physical and Environmental Protection), PL (Planning), PM (Program Management), PS (Personnel Security), PT (PII Processing and Transparency), RA (Risk Assessment), SA (System and Services Acquisition), SC (System and Communications Protection), SI (System and Information Integrity), SR (Supply Chain Risk Management).

PE (physical environment) doesn't apply if you're running on AWS. MA (hardware maintenance) doesn't either. PM and PS are org-level concerns, not application concerns. What's left for a web app? Six families do most of the work.

SC: System and Communications Protection

This is where transmission security lives. SC-8 (Transmission Confidentiality and Integrity) requires encryption in transit. For web apps, that means TLS 1.2 minimum, TLS 1.3 preferred. Cipher suites matter too - RC4 and 3DES are out.

SC-28 covers protection of information at rest. Databases, file storage, session tokens - anything sensitive that persists. SC-7 defines boundary protection, which affects what ports are exposed and how internal services communicate. If you terminate TLS at a load balancer and pass plaintext to backend services, SC-7 and SC-8 both have opinions on that.

SC-5 is denial-of-service protection. SC-12 covers cryptographic key establishment and management. SC-23 addresses session authenticity - protect your session tokens, rotate them on privilege changes, expire them properly.

IA: Identification and Authentication

IA-2requires multi-factor authentication for privileged accounts. IA-2(1) extends MFA to all user accounts for systems targeting the Moderate baseline - which is most commercial SaaS. If you're still offering password-only login, this control fails.

IA-5 is authenticator management. It governs password complexity, rotation policy, storage requirements (no plaintext, no MD5, no unsalted SHA-1), and recovery mechanisms. IA-8 covers identification and authentication for non-organizational users - everyone who signs up through your public registration form.

SI: System and Information Integrity

SI-2(Flaw Remediation) requires a process for tracking and patching vulnerabilities. That means identifying flaws, testing patches, and installing them within an organization-defined timeframe. Critical CVEs don't get indefinite deferral.

SI-3 covers malware protection for systems where it applies. SI-10 handles input validation - check all inputs for validity before processing. SI-11 is error handling: generate informative error messages for authorized users, but do not expose system internals to unauthorized users. Stack traces in production responses fail SI-11.

RA-5 (Vulnerability Monitoring and Scanning) belongs to the RA family but sits next to SI-2 in practice. You need regular automated scans and a documented process for addressing what they find.

AU, SA, CM: Also in Scope

AU (Audit and Accountability) defines what to log and how to protect those logs. AU-2 lists auditable events. AU-3 specifies record content: timestamps, user IDs, event types, source addresses, outcomes. AU-9 protects audit information from unauthorized access and modification. Web apps commonly under-log (no user ID on failed authentication) or log the wrong things (full request bodies containing credentials).

SA (System and Services Acquisition) covers the development process. SA-3 is the secure systems development life cycle control. SA-11 requires developer security testing - code reviews, static analysis, dynamic testing. SA-9 applies to your third-party services and cloud providers. If a vendor handles your data, their security practices are your responsibility under SA-9.

CM (Configuration Management): CM-6 requires secure configuration baselines. CM-7 mandates least functionality - disable services, ports, protocols, and functions you don't need. For a web server, that means: directory listing off, default credentials changed, unused HTTP methods blocked.

How NIST 800-53 Maps to NIS2

If you're an EU entity subject to the NIS2 Directive (Directive (EU) 2022/2555), the Article 21 technical requirements overlap substantially with NIST 800-53:

Using NIST 800-53 as your implementation framework does not automatically satisfy NIS2. The EU-specific requirements - 24-hour early warning to national CSIRTs, 72-hour incident notification, management liability under Article 20 - are outside NIST's scope. But the technical control catalog covers most of Article 21. For multinational organizations handling both, this overlap reduces duplication.

Where to Start

For most web applications, the practical starting point is four controls: SI-2 (patch management), RA-5 (vulnerability scanning), SC-8 (TLS configuration), and IA-2 (MFA). Getting those right exposes the next layer of gaps.

Run a scan against your production URL. The results surface SC-8 failures (HTTP-only, weak ciphers), IA-5 issues (password policy gaps), and CM-7 misconfigurations (exposed ports, directory listing, default banners) in one pass. That narrows the 1,189-control catalog to a manageable list of actual findings.

NIST 800-53B has the official Moderate baseline control list. For web applications specifically, the OWASP Application Security Verification Standard (ASVS) maps well to NIST 800-53 and is written in developer-accessible language. The two are complementary.

ismycodesafe.com runs 200+ automated checks covering SC, IA, SI, and CM control gaps. Not a full 800-53 assessment - that requires documentation review and interviews - but it catches the surface-level issues that show up as findings in every audit.