What Is NIST SP 800-228?

NIST created SP 800-228 to help organizations protect APIs that connect modern enterprise systems, with a strong focus on cloud-native architectures. Its scope is broader than a vulnerability list. The document connects three questions:

1. What can go wrong? It analyzes API risk factors and vulnerabilities across development and runtime.
2. What should be done? It recommends basic and advanced controls before runtime and during runtime.
3. Where should controls run? It compares implementation patterns and trade-offs for gateways and other protection components.

The document explicitly supports an incremental, risk-based approach. It separates “basic” controls that organizations should pursue immediately from “advanced” controls that often require deeper request/response analysis or richer metadata.

What Changed in the March 2026 Update?

NIST’s March 13, 2026 update added two substantive appendices:

• Appendix D — List of API Risks by Risk Categories: a consolidated mapping of API risks to categories such as visibility, authorization, authentication, resource consumption, sensitive information, input processing, and identity/credential-management concerns.
• Appendix E — List of Recommended Security Controls by API Lifecycle Stage: a consolidated list of the control IDs, their basic/advanced classification, lifecycle stage, and primary control task.

These additions do not replace the detailed explanations in Sections 2–4. They make the document easier to use as an implementation checklist because teams can start with the appendix tables, then return to the relevant section for context and trade-offs.

The updated document’s change log identifies both additions as substantive changes dated March 13, 2026.

The API Risks NIST SP 800-228 Emphasizes

SP 800-228 begins with the problem of visibility. It states that organizations cannot protect an API estate they do not accurately inventory, and it calls out rogue or shadow APIs as well as zombie or deprecated APIs. From there, it covers authorization, authentication, resource consumption, sensitive-data leakage, input validation, and identity patterns that can create confused-deputy or trust-boundary problems.

This framing is valuable because it treats API security as more than injection prevention. Authorization, identity propagation, runtime inventory, resource exhaustion, and response data are first-class concerns.

How NIST Organizes API Security Controls

Section 3 divides controls along two dimensions: when the control applies and how deeply it analyzes the API.

NIST’s distinction is practical. Basic protections generally operate on connection or request metadata and provide foundational coverage. Advanced protections often need deeper payload inspection, semantic context, or more granular policy. The document notes that deeper inspection can add CPU and latency cost, so organizations should apply advanced controls according to risk.

Key Pre-Runtime Protections

Maintain a specification for every API

REC-API-1 says all APIs must have a specification describing the endpoints they expose. REC-API-2 recommends a well-defined interface description language such as OpenAPI for HTTP/REST or protobuf definitions for gRPC. The goal is to give security and tooling a machine-readable definition of expected behavior.

Define request and response schemas

REC-API-3 calls for request and response schemas for each endpoint, including validation guidance for field values. This is important for security because a schema provides the positive model that runtime controls can enforce.

Create centralized API governance and inventory

REC-API-4 and its sub-controls address governance, an API platform team, organizational inventory, visibility tools, and versioning/deprecation. The publication specifically recommends API discovery and automated scans to identify running APIs.

Enrich schemas with security meaning

Advanced pre-runtime controls go beyond syntax. NIST recommends annotating fields as public/internal or by trust level, annotating permissions, and marking semantic data types such as PII, PHI, or payment information. This lets runtime systems enforce policy based on what a field means, not only its JSON type.

Reconcile declared APIs with live traffic

REC-API-8 adds runtime information to the inventory and calls for discovery during runtime so teams can reconcile specifications with what is actually deployed. That creates a direct control against shadow, orphan, and zombie endpoints.

Key Runtime Protections

NIST says to apply zero-trust principles as a baseline for runtime API protection and augment them with policy on requests and payloads. The recommended controls are detailed; the following groups are the most operationally important.

Encrypt runtime communication

REC-API-9 requires runtime communication to be encrypted, including APIs that serve public or unauthenticated data. The objective is confidentiality and integrity in transit.

Validate requests and responses

REC-API-10 and REC-API-13 cover general request/response validation and schema-based validation. The response side matters: an API can accept a safe request and still expose unexpected data in the response.

Authenticate both user and service identities

The REC-API-11 family covers credential handling, brute-force protection, user/service authentication, cryptographically verifiable identities, standard authentication mechanisms, secure token handling, and signature verification. This is especially relevant in microservice architectures where a request may carry both end-user and workload identity.

Enforce authorization as a separate decision

REC-API-12 and related controls address authorization models and auditability. Authentication proves who or what is calling; authorization determines whether that caller may perform the requested action on the specific resource.

Limit resource consumption

REC-API-15 and REC-API-16 cover rate limiting, timeouts, bandwidth and payload limits, user-supplied query limits, concurrent requests, threshold strategies, and real-time monitoring. NIST also distinguishes rate limits from quotas, which is useful when designing controls for short-term abuse versus longer-term entitlement.

Monitor and block with context

REC-API-17 calls for fine-grained request/user blocking and REC-API-18 requires monitoring API access. Advanced runtime controls add field-level validation and authorization, semantic data policy, non-signature payload scanning, anti-enumeration protections, sensitive-data exposure controls, and fine-grained request blocking.

This is where runtime security platforms can complement gateways and application logic: the important capability is not simply “block API attacks,” but to show which NIST-style outcome is enforced, what evidence supports it, and whether the traffic can bypass that enforcement point.

Implementation Patterns and Gateway Trade-Offs

Section 4 is one of the most useful parts of SP 800-228 because it does not assume every API control belongs in one product. NIST identifies core capabilities such as authentication/authorization, request and response validation, rate limiting, circuit breaking, error handling, logging, and monitoring, then discusses how architecture affects enforcement.

The document analyzes centralized, hybrid, and distributed API gateway patterns. The central question is where policy is enforced relative to clients, services, and service-to-service traffic.

NIST also discusses WAF, bot detection, DDoS mitigation, API endpoint protection, and WAAP as related implementation components. This reinforces a key principle: API protection is a control architecture, not a single appliance category.

A Practical SP 800-228 Implementation Roadmap

You do not need to implement every advanced control on day one. A risk-based rollout can follow the document’s basic/advanced distinction.

1. Establish inventory and ownership. Combine API specifications, gateway configuration, source repositories, cloud/platform data, and runtime discovery. Identify shadow, deprecated, and unknown APIs.
2. Standardize specifications and schemas. Require machine-readable API definitions and request/response schemas for new APIs; prioritize critical existing APIs for remediation.
3. Protect identity. Define approved authentication standards, user/service identity propagation, token validation, and authorization responsibilities.
4. Enforce basic runtime controls. Encryption, validation, rate/concurrency/payload limits, timeouts, monitoring, and targeted blocking should cover the highest-value paths first.
5. Add response and semantic context. Classify sensitive fields, inspect responses, and move toward field-level authorization and data-flow policy where risk justifies it.
6. Close bypass paths. Verify that APIs cannot be reached around the gateway, mesh, proxy, or runtime security layer that is expected to enforce policy.
7. Operationalize telemetry. Send API security events to the SOC with endpoint, identity, policy, request/response context, and action evidence.
8. Measure and improve. Track coverage, unknown APIs, policy exceptions, false positives, abuse findings, sensitive-data exposure, and time to remediation.

Ammune’s enterprise DevSecOps API security guide provides a complementary lifecycle view for connecting design and runtime controls.

NIST SP 800-228 vs OWASP API Security Top 10

They serve different purposes and work well together. OWASP API Security Top 10 is a risk-awareness resource that highlights common and important API security problem areas. NIST SP 800-228 is more explicitly organized around lifecycle controls and architectural implementation choices.

What About NIST SP 800-228A?

Do not confuse SP 800-228 with SP 800-228A. As of September 2026, SP 800-228A, Guidelines for the Secure Deployment of RESTful Web APIs, is an Initial Public Draft published May 18, 2026. Its public comment period closed July 2, 2026.

NIST describes 800-228A as a REST-specific companion that complements SP 800-228 with parameters tailored to RESTful Web APIs. Because it is still a draft, organizations should clearly label any use of 800-228A recommendations as draft guidance rather than treating them as final NIST guidance.

How Ammune Can Support an SP 800-228-Oriented API Security Program

Ammune is most directly relevant to the runtime and visibility parts of an SP 800-228 program. It can be evaluated for API discovery, reconciliation of live traffic with expected APIs, request and response inspection, sensitive-data visibility, behavioral detection, Layer 7 protection, policy enforcement, forensics, and SIEM-ready evidence.

That does not replace API specifications, secure development, strong application authorization, identity systems, gateway policy, or DevSecOps governance. The useful question is which control outcomes Ammune can provide at runtime and how those outcomes fit the organization’s broader control architecture.

For a deeper runtime view, see API runtime security protection. For procurement and validation, use the API security vendor evaluation checklist to turn control claims into measurable tests.

Frequently Asked Questions