A microservices architecture builds an application as many small, independently deployed services that talk to each other over APIs. It speeds up development and scaling. It also turns internal function calls into network calls, so you must secure authentication, communication and monitoring between services, not only at the front door.
What does NIST say?
NIST SP 800-204, Security Strategies for Microservices-based Application Systems, notes that the smaller codebase speeds code development, testing and deployment, supports independent teams, and lets each component scale on its own. It also says microservices generally communicate through APIs, and lists the core features that interaction requires: authentication and access management, service discovery, secure communication protocols, security monitoring, resiliency techniques such as circuit breakers, load balancing and throttling, integrity assurance when new services are added, and handling of session persistence.
That list is a handy design checklist. If a feature on it is missing from your platform, someone is solving it per service, and some will do it badly.
What changes compared with a monolith?
More paths. Calls that stayed inside one process now cross the network. Each is a path an attacker can use after getting a foothold.
Identity for services. Services need identities and need to prove them to each other. Shared network location is a weak proxy.
Authorization at every hop. A request that passed the gateway should not be trusted blindly by the tenth service behind it. NIST also publishes companion guidance, SP 800-204A, on building secure microservices-based applications with a service mesh.
Many dependencies. Fifty services may use fifty sets of libraries. A flaw in a common package affects many places at once.
Operational sprawl. Logs, configs and secrets are spread widely, and services come and go.
What does a constructed failure look like?
An online shop has a gateway that checks user login, then forwards to an orders service, which calls an invoices service. The invoices service trusts any call from inside the cluster. A bug in a low-importance image resizing service lets an attacker make requests from inside. They call the invoices service directly and read other customers' invoices. A policy that required each service to present its own credential, and limited which services could call invoices, would have stopped the pivot.
When are microservices not worth it?
Small teams with a single product often do well with a well-structured monolith. Splitting too early creates network calls, deployment pipelines and observability work that the team has not got time to secure. Move to microservices when independent scaling or team boundaries justify the cost, and keep a short written reason. If you do split, start with one or two services and learn the security patterns before you have fifty.
How do you test it?
Testing changes shape too. Unit tests cover one service, but the risky bugs sit between services. Write tests that call a service with the wrong identity, with an expired token, or with another tenant's ID, and check that each is refused. Run them in your pipeline against a test environment. Add contract tests so a change in one service's API does not silently remove a check another depends on.
How to check or apply this
- Draw a map of services and calls between them. Mark which calls cross trust boundaries.
- Give each service its own identity, and use mutual authentication for service-to-service calls.
- Encrypt internal traffic. Do not rely on a private network alone.
- Write an allow list of which services may call which, and deny the rest by default.
- Check authorization in each service that handles sensitive data, not only at the gateway.
- Add rate limits and circuit breakers so one failing service does not take down the others.
- Generate a software bill of materials for each service, and watch dependencies centrally. Safeguard's SBOM and dependency scanning and reachability analysis suit this job.
- Centralise logs and trace requests across services, so you can follow one request end to end.
Quick check
Are microservices more secure than a monolith?
Not by default. They can limit blast radius if designed that way, and they add network paths and moving parts that must be secured.
Is an API gateway enough?
No. A gateway protects the entrance. Services behind it also need to authenticate callers and check permissions.
Sources
- NIST SP 800-204, Security Strategies for Microservices-based Application Systems
- NIST SP 800-204A, Building Secure Microservices-based Applications Using Service-Mesh Architecture
Last reviewed: 18 October 2026.
