Guide to NIST SP 800-228 and Why it Changes Everything

Buchi Reddy B

CEO and Founder at Levo

99% of organizations faced API security incidents last year—yet only 10% had an API posture governance strategy in place. 

That number still hasn’t improved.

Why? 

Because in most enterprises, API security remains fragmented—plagued by tribal workarounds, vendor-specific tools, and runtime-first thinking.

The problem isn’t awareness. It’s the absence of structure.

NIST’s SP 800-228 closes this gap—not with vague principles, but with concrete, lifecycle-aligned controls built for software that’s no longer linear, centralized, or predictable.

OWASP API Top 10 outlines threats. NIST SP 800-228 provides the structure to preempt them.

It defines controls across the full lifecycle (pre-runtime and runtime) anchored in how APIs are designed, deployed, and governed. 

Make no mistake—despite being voluntary, SP 800-228 now sets the bar for what robust API Security and Security Posture looks like.

Compliance teams trust it. Customers recognize it. And in high-risk environments, that trust becomes leverage.

In the sections ahead, I will break down the specific controls NIST recommends, where they belong, and how Levo helps embed them seamlessly without diminished developer velocity or slowed-down pipelines.

Why Fragmented API Security Is Failing—and What NIST Does Differently

At Levo, we’ve always believed that security needs to be architected from the first line of code and within every stage of the SDLC. 

And like many other regulatory bodies like RBI, Indian Ministry of Electronics and PCI, NIST formalizes that view in SP 800-228.

NIST’s last API-related publication, SP 800-95, was rooted in SOAP, WSDL, and statically defined web services. 

SP 800-228, by contrast, responds to the architectural shift enterprises have already made: cloud-native applications running microservices, communicating via REST, GraphQL, and gRPC APIs, governed by distributed identity and deployed continuously via CI/CD.

It negates API Security as a production-only concern and encourages enterprises to embed security controls throughout the entire API lifecycle. 

It segments API security into two operational domains:

What We’ve Always Believed—Now Backed by SP 800-228

SP 800-228 defines API visibility as the combined ability to discover, document, and classify every API—internal, external, or third-party across environments. 

The rationale is simple: you can’t govern or protect what you can’t see. 

That means enterprises must:

All of this must be kept current as APIs are deployed, updated, or deprecated. 

These guidelines are sound in theory, but they're impossible to maintain manually at scale. 

With 60% of enterprises pushing API updates weekly and only 6% of developer time spent on docs, visibility decays fast. And when it does, APIs turn into security blind spots.

Secure Every API Without Slowing Down the Developers Who Build Them

Levo eliminates the API Sprawl that stalls revenue expansion and exposes APIs to risk. By automating discovery and spec generation, it ensures your APIs are secure, integration-ready, and monetizable without breaking developer velocity or adding security headcount.

Data Protection Into a Built-In Advantage—Not a Bottleneck

Pre-Production Security Testing Is How Security Posture Gets Locked In

 SP 800-228 recommends enforcing secure authentication for every API request and applying fine-grained, field-level authorization to restrict access based on roles and scopes. 

To implement this, enterprises must adopt standardized and verifiable mechanisms like OAuth2, JWTs, mTLS, and SAML for identity validation—then layer endpoint, resource, and field-level access rules on top.
Every request must be tied to a known identity, every field exposure decision evaluated in real time, and authorization logic aligned across services and environments.

It also recommends hardening every API against enumeration attacks by validating every payload against strict schemas, enforcing rate limits to prevent overuse, and filtering untrusted query parameters.

To close off avenues for denial of service and data exfiltration it recommends schema validators in code and middleware, bandwidth and payload caps, and short-duration rate limits tailored by user identity not just by endpoint. 

But implementing those correctly across environments, sprint cycles, and services is nearly impossible manually.

That’s why Pre-Production API Security Testing is a non-negotiable if enterprises want to avoid security incidents and data breaches.  

Modern applications can’t wait weeks for manual security tests. 

To keep up with development velocity, security needs to be continuous, pre-production, and precise, aligned with the nature of modern software development. 

That’s exactly what Levo delivers: 100x more coverage and frequency at 1/10th the cost, so you don’t have to choose between Security Posture and Velocity. 

To meet SP 800-228’s mandate of access and abuse controls, Levo simulates real-world exploits tailored to each API’s logic—so you detect and remediate attack paths before they cost you users, trust, or compliance.

Shift Left Reduces Risk But Can’t Replace Runtime Guardrails

While SP 800-228 emphasizes shift-left security, it also acknowledges a critical truth: not all API risks can be caught pre-production—many only surface at runtime, where behaviors emerge, configurations drift, and exposure peak.

Misconfigurations often surface only at runtime, when APIs are live, dynamic, and most vulnerable.

That’s why the framework calls for continuous runtime enforcement:

But as APIs scale across environments and owners, visibility fractures.

Without unified runtime observability, telemetry gets lost between clouds, enforcement logic drifts from spec to runtime and foundational controls like TLS enforcement or token verification fail.

Levo’s API Monitoring module turns runtime enforcement into a programmable, policy-driven control layer.

Our passive sensors inspect every API call across staging, pre-prod, and production environments surfacing 50+ misconfigurations by default, including: 

But we don’t stop at generic checks. Levo lets teams write passive scanning rules in Python or YAML—so you can adapt enforcement to your own security policies, applications, endpoints and industry.

Build on top of hundreds of pre-modeled rulesets or define new ones in minutes.

Every issue is enriched with context: service ownership, environment, auth method, call frequency, last-seen timestamp.

Levo’s passive monitoring makes runtime security scalable by offering full customization without the overhead of building in-house scanning.

By automating API visibility, security testing, and runtime monitoring, Levo strengthens Security Posture—so NIST SP 800-228 compliance becomes a natural byproduct, not a separate initiative. 

Book a demo through this link to see this live in action!