An executive-level overview of NIST SP 800-228 and its guidance for securing APIs in cloud-native environments.
Introduction: The API Security Mandate
In today’s cloud-first enterprise landscape, Application Programming Interfaces (APIs) are the backbone of digital transformation, enabling service connectivity, innovation, and customer engagement. Yet, APIs are also the fastest-growing attack surface—and one of the least consistently protected.
On June 27, 2025, the National Institute of Standards and Technology (NIST) released the final version of Special Publication (SP) 800-228, "Guidelines for API Protection for Cloud-Native Systems." This landmark document provides a structured, risk-based approach to securing APIs in modern, cloud-native environments. Grounded in Zero Trust principles and DevSecOps practices, SP 800-228 delivers an actionable roadmap for CISOs seeking to align security and business agility.
This blog (Part 1) analyzes the final publication, summarizing its key guidance to help you identify where to focus your API security investments and efforts. In a follow-up post (Part 2), we will examine how Radware's solutions align with and support these guidelines.
Executive Summary of NIST SP 800-228
NIST SP 800-228 is designed to help organizations implement API protections across the development lifecycle and runtime stages. It applies to internal and external APIs, including those exposed to customers, partners, or other services. The publication is built on three guiding principles:
- Treat APIs as products requiring full lifecycle security
- Enforce Zero Trust at the service level. This means enforcing a 'never trust, always verify' approach where every API communication is subjected to rigorous authentication and authorization checks, ensuring that both the calling service and the end-user are verified and have the necessary permissions
- Deploy incremental, risk-based controls aligned to DevSecOps phases
This blog mirrors NIST’s structure, focusing on three pillars:
1. API Threat Landscape – Understanding the Risk Surface
We begin by examining the most critical and recurring vulnerabilities associated with APIs, such as shadow APIs, weak authorization, resource abuse, and sensitive data exposure. This section helps CISOs understand the “why” behind NIST’s guidance and the real-world consequences of poor API governance.
2. Control Framework – Mapping Protections Across the Lifecycle
Next, we delve into the control model NIST proposes—categorizing safeguards based on when they are applied (pre-runtime vs. runtime) and how mature the implementation is (basic vs. advanced). This section helps organizations adopt a DevSecOps-aligned, incremental roadmap for building resilient APIs.
3. Deployment Patterns – Architecting for Zero Trust and Scalability
We then explore the architectural approaches outlined in SP 800-228, including API gateways, service meshes, sidecars, and egress gateways. These deployment models offer flexibility in achieving runtime enforcement, Zero Trust segmentation, and backward compatibility with legacy systems.
1. Understanding the API Threat Landscape
NIST highlights several high-risk categories of API vulnerabilities:
| CATEGORY |
EXAMPLE RISK |
BUSINESS IMPACT |
| VISIBILITY |
Shadow, zombie, or undocumented APIs evade inventory and monitoring |
Creates blind spots, undermining compliance, and increasing breach detection time |
| AUTHORIZATION |
Weak or missing access controls at object, field, or function levels |
Leads to privilege escalation, data leakage, or lateral movement |
| AUTHENTICATION |
Insecure token validation, default credentials, weak token integrity |
Enables impersonation, session hijacking, and unauthorized access |
| RESOURCE ABUSE |
DoS attacks, excessive compute or cloud billing costs |
Service outages, degraded SLAs, financial and reputational damage |
| DATA EXPOSURE |
Verbose errors, unfiltered fields, unprotected data elements |
Leakage of sensitive data (PII, credentials), legal and compliance risks |
| INPUT VALIDATION |
Insufficient verification of input data, enables injection attacks |
Service disruption, Data corruption, and potentially full system compromise |
*NIST also highlights the critical importance of credential canonicalization. This involves standardizing how API gateways or enforcement points interpret and represent credentials, such as user IDs or tokens, to prevent attackers from bypassing authorization checks through varied or malformed inputs.
These threats expose gaps in governance, increase incident response costs, and often stem from inadequate visibility or inconsistent security policies.
2. A Control Framework for API Security
NIST SP 800-228 provides a framework organized along two dimensions:
- Lifecycle Phase:
- Control Maturity:
- Basic controls are foundational protections for common risks.
- Advanced controls provide fine-grained enforcement, visibility, and adaptive defense, necessary in sensitive or high-risk environments.
Choosing Basic vs. Advanced Controls
Basic controls serve as an essential baseline, particularly for internal or lower-risk APIs. However, NIST emphasizes a risk-based, progressive adoption model: as APIs become more critical, exposed, or regulated, advanced controls become necessary to achieve Zero Trust, ensure compliance, and prevent business disruption.
API Security Controls by Lifecycle Phase and Maturity
| Lifecycle Phase |
Control Level |
Example Controls |
Purpose / Business Value |
| Pre-runtime |
Basic |
- Enforce API spec (e.g., OpenAPI)
- Schema validation
- Ownership tagging
|
Standardizes API behavior, prevents drift, improves audit trails, and enables shift-left security |
| Advanced |
- Sensitivity tagging (PII, PCI)
- Permission annotations
- Contract testing with synthetic users
|
Helps enforce least-privilege, ensures compliance with data protection laws, and improves change control |
| Runtime |
Basic |
- mTLS / API keys
- DoS rate limiting
- Basic bot detection
- WAF inspection
|
Protects against volumetric attacks, unauthorized use, and OWASP API Top 10 threats |
| Advanced |
- Fine-grained access controls
- Identity-aware segmentation (e.g., service-to-service trust)
- Runtime telemetry and alerting
|
Supports Zero Trust, reduces lateral movement, enables forensic analysis and real-time response |
When Should Organizations Adopt Advanced Controls?
According to NIST SP 800-228, organizations should evaluate API sensitivity and exposure to determine when advanced controls are required. Consider upgrading beyond basic controls when:
- APIs handle sensitive or regulated data (PII, PHI, financial, etc.)
- APIs are externally exposed or integrated with third parties
- Business continuity or SLA compliance depends on the API
- You are implementing Zero Trust architectures at the service level
- Industry compliance (e.g., GDPR, PCI-DSS, HIPAA) imposes stricter control obligations
This control framework enables organizations to incrementally strengthen API security based on risk, maturity, and architecture. It aligns with modern DevSecOps principles by enabling early validation (shift-left) and real-time protection, making it a practical guide for securing APIs in cloud-native environments.
3. Deployment Patterns and Trade-Offs
Implementing API security in cloud-native environments isn’t just about choosing the right controls—it also requires choosing where and how those controls are enforced. NIST SP 800-228 identifies several common deployment patterns that can serve as enforcement points for both pre-runtime and runtime protections.
These architectural models help organizations embed API controls across a range of infrastructure types, from modern microservices to legacy systems. Each model supports different levels of visibility, enforcement granularity, and scalability, making it critical to match the right pattern to the right environment.
Deployment Models Overview
| Model |
Definition |
Security Role |
Strengths |
Trade-Offs / Limitations |
| API Gateway |
A centralized entry point for managing and securing external-facing APIs |
Policy enforcement, authentication, rate limiting, schema validation, logging |
Mature toolsets, high control over ingress, good observability |
May struggle with east-west (internal) traffic; risk of becoming bottlenecked |
| Service Mesh |
A distributed layer that handles service-to-service communication via sidecars (e.g., Istio, Linkerd) |
Enables identity-aware routing, mTLS, fine-grained access, telemetry |
Ideal for Zero Trust, strong encryption & microservice control |
Operational complexity, steep learning curve, requires Kubernetes-native architecture |
| Sidecar Proxy |
Lightweight local proxy deployed alongside each microservice (outside of full mesh control) |
Traffic inspection, API mediation, security retrofitting for legacy apps |
Avoids code changes, can wrap older apps, incremental adoption |
Lacks centralized visibility unless integrated into mesh/gateway |
| Egress Gateway |
An outbound proxy that mediates calls from internal services to third-party APIs |
Enforces outbound authentication, DLP, token injection, visibility on third-party calls |
Controls exfiltration risk, API key governance, shadow IT control |
Only applies to outbound flows, requires network egress standardization |
CISO Insight: Choosing the Right Model
“There is no one-size-fits-all model. Most enterprises use a combination of these patterns to support hybrid architectures and varying risk levels.”
- API gateways are excellent for customer-facing APIs and third-party integrations, where ingress security and throttling matter most.
- Service meshes are suited for internal microservice security, where Zero Trust and service identity enforcement are needed.
- Sidecars offer a middle ground when working with legacy workloads that cannot be easily refactored into a mesh.
- Egress gateways are crucial for controlling data exfiltration and managing third-party dependencies, especially in regulated sectors.
Your architecture should evolve based on:
- API exposure level (public vs. internal)
- Organizational maturity with Kubernetes and containers
- Compliance obligations
- Business risk tolerance
WAF/WAAP consideration
Beyond these core architectural patterns, Web Application Firewalls (WAFs) and more comprehensive Web Application and API Protection (WAAP) solutions play a crucial role in safeguarding APIs. While API gateways handle traffic management and basic security policies, WAFs and WAAPs provide deeper Layer 7 threat protection, defending against common API attacks like injection, broken authentication, and excessive data exposure. They are often deployed in conjunction with API gateways or as a standalone layer to offer advanced capabilities such as behavioral analytics, bot management, and API schema validation, complementing the controls enforced by service meshes and sidecars.
NIST SP 800-228 does not prescribe a single deployment model. Instead, it encourages organizations to adopt security enforcement where it makes the most sense, based on architectural realities and business priorities. The key is to embed consistent security principles (e.g., Zero Trust, visibility, enforcement points) across all layers—not just at the perimeter.
Conclusion
In our next post, we will explore how Radware empowers enterprises to operationalize NIST SP 800-228 guidelines—enhancing visibility, strengthening runtime defenses, and supporting secure deployment patterns across hybrid and cloud-native architectures. Stay tuned to learn how Radware can help your organization achieve API resilience and Zero Trust maturity.