Most organisations cannot say how many APIs they run, who owns them, or which of them check that the caller is allowed to see the data it asks for, and NIST SP 800-228 is the first NIST publication that sets out a control baseline for exactly that problem. SP 800-228, Guidelines for API Protection for Cloud-Native Systems, by Ramaswamy Chandramouli (NIST) and Zack Butcher (Tetrate), was first published in June 2025 and updated on 13 March 2026 (SP 800-228 upd1), which added an appendix of API risks by category and an appendix of controls by life cycle stage. It organises 26 numbered recommendations (REC-API-1 to REC-API-26) into pre-runtime and runtime controls, each split into basic and advanced. This guide explains the structure, the identity requirements that matter for service accounts, API keys and tokens, how to implement and evidence the controls, and how they map to SP 800-53, CSF 2.0 and the OWASP API Security Top 10. For general API security practice see the API Security Guide; this page stays with the NIST text.
Key takeaways
- It is a zero trust document for APIs. The executive summary treats every API, internal and external, as in scope for zero trust, and the controls assume there is no trusted perimeter.
- Controls are split four ways. Pre-runtime basic (REC-API-1 to 4), pre-runtime advanced (5 to 8), runtime basic (9 to 18) and runtime advanced (19 to 26) give a natural maturity path.
- Authenticate and authorise both callers. REC-API-11-2 and REC-API-12 require authenticating and authorising the calling service and the end user on every request, even when the end user is itself a non-person entity.
- Order matters. REC-API-14 requires authenticate, then authorise, then validate, so that validation errors do not leak information to callers who should not see them.
- Inventory is the first control. REC-API-4.2 and REC-API-8 require an organisational inventory that includes shadow and zombie APIs, with owners and runtime data reconciled against declared specifications.
What it is and who it applies to
SP 800-228 is a Special Publication in NIST's 800 series. It is guidance: federal agencies use it alongside SP 800-53 controls, and private organisations adopt it voluntarily. Its keywords on the CSRC page are API, API endpoint, API gateway, API key, API schema and web application firewall.
| Document | Status (checked 27 October 2026) | Scope |
|---|---|---|
| SP 800-228 (June 2025) | Withdrawn 13 March 2026, superseded by upd1 | Original final text |
| SP 800-228 upd1 (13 March 2026) | Final | Adds Appendix D (API risks by risk category) and Appendix E (controls by life cycle stage) |
| SP 800-228A (18 May 2026) | Initial Public Draft; comments closed 2 July 2026 | Guidelines for the Secure Deployment of RESTful Web APIs: extends the SP 800-228 controls with REST-specific parameters |
The audience is anyone who designs, deploys or operates APIs in cloud-native systems: platform and API gateway teams, service owners, security architects and assessors. Because SP 800-228A is a draft, avoid building contractual or audit requirements on its specific wording until it is final.
Structure and key requirements
The document runs from an introduction (zero trust and APIs, the API life cycle, relationship to other NIST documents), through API risks (Section 2), recommended controls (Section 3) and implementation patterns (Section 4), to appendices covering an API classification taxonomy, DevSecOps phases, limit types, risks by category and controls by stage. The life cycle follows the DoD Enterprise DevSecOps model: pre-runtime is Plan, Develop, Build, Test and Release; runtime is Deploy, Operate, Monitor and Feedback.
The six risk categories (Section 2)
- Lack of visibility of APIs in the enterprise inventory
- Missing, incorrect or insufficient authorisation
- Broken authentication
- Unrestricted resource consumption (compute and physical)
- Leaking sensitive information to unauthorised callers
- Insufficient verification of input data
Section 2.7, credential canonicalisation, is a preparatory topic rather than a risk category: it covers how identities are carried and translated across gateways and how that can create a confused deputy.
The control baseline (Section 3)
| Group | IDs | What they require |
|---|---|---|
| Pre-runtime basic | REC-API-1 to REC-API-4 (with 2-1, 4.1 to 4.4) | A specification for every API in a well-defined IDL (OpenAPI, gRPC, Thrift, SOAP), request and response schemas, centralised API governance, a self-service platform, an inventory including shadow and zombie APIs, discovery scans, and versioning and sunsetting plans |
| Pre-runtime advanced | REC-API-5 to REC-API-8 | Validation rules in the spec using constrained primitive types, field annotations for public or internal and required permission, semantic type labels (PII, PHI, PCI), and runtime data reconciled into the inventory |
| Runtime basic | REC-API-9 to REC-API-18 | Encrypt all traffic, early request filtering (WAF, bot, DoS), robust authentication, per-request authorisation of service and user, schema validation, the authenticate-authorise-validate order, usage and rate limits, fine-grained blocking, and tagged telemetry |
| Runtime advanced | REC-API-19 to REC-API-26 | Field-level semantic validation at every hop, resource and field-level authorisation from annotations, mandatory access control on labelled fields, payload scanning for generative AI APIs, anti-enumeration error codes, response and log masking, and blocking of query-of-death requests |
Rate limiting specifics
- Limit everyone: REC-API-15-1 applies rate limits to all callers, including internal ones, with TCP and application timeouts (15-2), bandwidth and payload limits (15-3) and caps on user-supplied parameters such as page sizes, time ranges and GraphQL query limits (15-4).
- Rate limits are not quotas: REC-API-16-1 is explicit that rate limits protect the system and need not be exact.
- Dimension and window: limit by user, IP or end-user credential rather than total load (16-2), over short windows such as 60 seconds or 5 minutes (16-3), using token bucket, leaky bucket or adaptive algorithms (16-5), and cap concurrency (16-6).
- Third-party APIs: REC-API-16-7 asks for real-time monitoring and hard limits on consumption of third-party APIs. See the Rate Limiting and API Abuse Guide.
Implementation patterns (Section 4)
| Pattern | How it works | Strengths | Weaknesses |
|---|---|---|---|
| Centralised gateway | All protections in one shared component near the perimeter; internal traffic hairpins through it | Single point to monitor and audit; fits a central API team; easy developer onboarding | Shared-fate outages, noisy neighbours, slow change, hard cost attribution, gateway bypass risk |
| Hybrid | Cross-cutting policy (such as authentication) centralised; application-specific policy (such as authorisation) owned by the application | Balances central control with team ownership | Split responsibility must be clearly documented |
| Distributed gateway | Policy enforced in gateways dedicated to each application, often a sidecar beside each instance | Fine-grained authorisation at every hop; less bypass risk; reduces confused deputy risk | More components to run and keep consistent |
NIST notes that all three patterns can implement all of the controls: the choice is an engineering trade-off. Where a centralised gateway is used, services must only accept traffic from the gateway, or the gateway can be bypassed. See the API Gateway Security Guide and the Service Mesh Security Guide.
Identity and NHI requirements
Most API callers are machines: services, jobs, partner integrations and, increasingly, AI agents. SP 800-228's authentication and authorisation controls are therefore largely non-human identity controls.
| Control | Requirement | NHI practice |
|---|---|---|
| REC-API-11-2 | Authenticate both the calling service and the end user (references SP 800-207A) | Every service gets its own identity; no shared "integration" accounts |
| REC-API-11-3 | Cryptographically verifiable identities, no weak algorithms or long expiry, rotated signing keys | Short-lived tokens and certificates; key rotation runbooks |
| REC-API-11-4 | Standard mechanisms: OIDC, OAuth 2, SAML for users; SPIFFE SVIDs, JWTs, API keys for services | Prefer workload identity (SPIFFE, cloud workload identity) over static API keys where possible |
| REC-API-11-5 | Opaque tokens for untrusted systems | Do not hand partners JWTs that reveal internal claims |
| REC-API-11-6 | Protect tokens in storage and transit; send in headers, not URLs | Vault storage; strip tokens from URLs and logs |
| REC-API-11-7 | Verify signatures and expiry (JWT exp, X.509 SVID validity) | Reject unsigned or expired credentials at every hop |
| REC-API-12, 12.1 | Authorise service and user per request; ABAC for service-to-service | Least privilege scopes per integration and per agent |
| REC-API-17 | Block individual users by credential or address | Ability to revoke one compromised key without an outage |
Section 2.7.3 gives SPIFFE X.509 identities over mutual TLS as an example of service identity. See the SPIFFE and SPIRE Guide, the mTLS Guide and the API Key Management Guide. For AI agents calling APIs, REC-API-22 adds payload scanning for generative AI APIs to detect sensitive content and prompt injection, and the dual service-plus-user authorisation in REC-API-12 is the pattern that stops an agent acting with more authority than the user it serves.
Implementation steps
- Build the inventory (REC-API-4.2, 4.3, 8). Combine gateway configuration, cloud API services, service mesh telemetry and code repositories. Record owner, specification, exposure (internal, partner, public), data classification and calling identities for each API. Flag shadow (unknown), orphan (no owner) and zombie (deprecated but live) endpoints.
- Require specifications (REC-API-1 to 3). Make an OpenAPI or gRPC definition a release gate. Start by generating specs from traffic for existing APIs, then move to spec-first for new ones.
- Fix authentication (REC-API-11). Remove unauthenticated internal endpoints, replace shared API keys with per-service credentials, shorten token lifetimes and move tokens out of URLs. Test in a staging environment with logging of rejected requests before enforcing.
- Enforce per-request authorisation (REC-API-12, 14). Check the service and the user on every request, in the order authenticate, authorise, validate. Add object-level checks for every endpoint that takes an identifier.
- Apply limits (REC-API-15, 16). Start in report-only mode to learn normal rates per caller, set limits above observed peaks, then enforce. Keep a per-caller override so a single limit can be relaxed without a release.
- Instrument (REC-API-18). Log at least timestamp, client ID, request and response status and endpoint identifier, tagged with API and service, plus enforcement results per policy class.
- Move to advanced controls. Add field annotations and semantic labels (REC-API-6, 7), field-level filtering (REC-API-20), anti-enumeration responses (REC-API-23, 24) and masking (REC-API-25) on the APIs that carry regulated data first.
- Plan rollback. Every enforcing policy change ships behind a gateway or mesh configuration flag with a tested revert, and a named owner on call for the first 48 hours.
Evidence and assessment
| Control area | Evidence an assessor can test | Metric |
|---|---|---|
| Inventory (REC-API-4.2, 8) | Inventory export reconciled against gateway and mesh traffic | Percentage of observed endpoints present in the inventory with an owner |
| Specification (REC-API-1 to 3) | Spec files in source control; release gate logs | Percentage of APIs with a current machine-readable spec |
| Authentication (REC-API-11) | Gateway policy; scan for unauthenticated endpoints | Count of unauthenticated non-public endpoints (target zero) |
| Credentials (REC-API-11-3, 11-6) | Token lifetime settings; vault records; key rotation logs | Median API key age; percentage of service callers on short-lived credentials |
| Authorisation (REC-API-12, 12.3) | Authorisation test results, including object-level tests | Authorisation test coverage of endpoints that take identifiers |
| Limits (REC-API-15, 16) | Rate limit policy per API; alert records | Percentage of APIs with per-caller limits enforced |
| Telemetry (REC-API-18) | Sample log records with required fields | Percentage of APIs sending tagged logs to the SIEM |
Detection worth building from that telemetry: one client ID reading far more distinct object identifiers than its baseline (bulk enumeration), spikes in 401 and 403 responses from one caller, an API key used from a new network or region, and traffic to endpoints marked deprecated. The T-Mobile API breach is the reference case: data on about 37 million accounts was pulled through one API over roughly six weeks before detection, which is exactly the per-caller volume pattern REC-API-16-2 and REC-API-24 target.
Mapping to other frameworks
| SP 800-228 control | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | OWASP API Security Top 10 2023 |
|---|---|---|---|
| REC-API-4.2, 8 inventory | CM-8 System Component Inventory | ID.AM-02 | API9:2023 Improper Inventory Management |
| REC-API-9 encryption | SC-8 Transmission Confidentiality and Integrity (cited in the text) | PR.DS-02 | API8:2023 Security Misconfiguration |
| REC-API-11 authentication | IA-5 Authenticator Management, IA-9 Service Identification and Authentication | PR.AA-05 | API2:2023 Broken Authentication |
| REC-API-12, 20 authorisation | AC-3 Access Enforcement, AC-4 Information Flow Enforcement | PR.AA-05 | API1:2023 BOLA, API3:2023 BOPLA, API5:2023 BFLA |
| REC-API-13, 19 validation | SI-10 Information Input Validation | PR.PS-02 (indirectly) | API8:2023 Security Misconfiguration |
| REC-API-15, 16 limits | SC-5 Denial-of-service Protection | DE.CM-01 | API4:2023 Unrestricted Resource Consumption |
| REC-API-16-7 third-party APIs | SR-3 Supply Chain Controls and Processes | ID.AM-02 | API10:2023 Unsafe Consumption of APIs |
| REC-API-18 telemetry | AU-2 Event Logging, AU-12 Audit Record Generation | DE.CM-01 | Supports detection across the list |
Relevant ATT&CK techniques for threat modelling are T1190 Exploit Public-Facing Application, T1528 Steal Application Access Token, T1552.001 Credentials In Files and T1499 Endpoint Denial of Service. SP 800-228 itself references SP 800-207A for zero trust service identity and SP 800-204B for service mesh authorisation.
Common pitfalls
- Trusting internal APIs: exempting east-west traffic from authentication contradicts the zero trust basis of the document. In the McKinsey AI platform hack, researchers reported 22 endpoints that accepted requests with no authentication, found through publicly exposed API documentation.
- Gateway without bypass protection: services that accept traffic directly from the network undo every gateway control.
- Shared, long-lived API keys: one key used by several services makes REC-API-17 blocking impossible without an outage and leaves no attribution.
- Authorising the service but not the user: a trusted backend that acts for any user it is told to is a confused deputy, which Section 2.7.6 calls out.
- Verbose validation errors: validating before authorising leaks schema and data details, the reason for REC-API-14 and REC-API-23.
- Inventory as a one-off project: without scheduled discovery (REC-API-4.3) zombie endpoints return within months.
Practitioner checklist
- Confirm you are working from SP 800-228 upd1 (13 March 2026), not the withdrawn June 2025 text.
- Stand up an API inventory with owners and reconcile it against traffic on a schedule.
- Make a machine-readable specification a release gate for new APIs.
- Give every calling service its own short-lived, verifiable credential.
- Authorise both the service and the end user on every request, in authenticate-authorise-validate order.
- Enforce per-caller rate limits on internal and external APIs, and hard limits on third-party API spend.
- Log the minimum fields to the SIEM and alert on per-caller enumeration and new-location key use.
- Map your controls to SP 800-53 and the OWASP API Top 10 for audit.
- Track SP 800-228A until it is final before adopting REST-specific parameters.
Standards and references
- NIST: SP 800-228 upd1, Guidelines for API Protection for Cloud-Native Systems
- NIST: SP 800-228 upd1 (PDF)
- NIST: SP 800-228A Initial Public Draft, Guidelines for the Secure Deployment of RESTful Web APIs
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- OWASP: API Security Top 10 2023
- MITRE ATT&CK: Steal Application Access Token (T1528)
Related NHI Mgmt Group resources: API Security Guide · API Gateway Security Guide · API Key Management Guide · Cloud Workload Identity Guide