Update, October 2026: NIST stopped developing draft SP 800-180, which this article listed, in January 2025. NIST’s guidance for microservices is SP 800-204 and its parts 800-204A to 800-204D; the container guidance in SP 800-190 and NISTIR 8176 still applies.
Compared to monolithic applications, which house all code in a single system, microservices are small, autonomous units that address individual functions and work with others to help an application function. This helps organizations deliver large and complex applications rapidly and more reliably.
Along with the many benefits of updating monolith systems tomicroservices architecture, there are also new security challenges that organizations need to address.
Instead of a single entry point, microservices offer many potential points of vulnerability, and as such each one needs to be effectively secured in order for an application to operate effectively.
Secure By Design
Integrate security into the development lifecycle by turning the DevOps model to DevSecOps. With a DevSecOpsmodel in place, performance, scalability, and security are weighed equally without any bias. Establish continuous tests like Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST).
SASTis a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. It is one of the most mature application security testing methods in use, its white-box testing, where source code is analyzed from the inside out while components are at rest. Understanding security flaws is the first step toward remediating security flaws and thus reducing software risk.
DAST is a process of testing an application or software product in its running state. DAST comes into play when an application has gone into production or entered runtime, after initial development phases. It is a black-box security testing technique in which the application is being tested without exposing the source code or the application architecture. In this way, it can cast a spotlight on the runtime issues which cannot be easily identified during a static analysis like the authentication and server configuration issues, as well as issues or vulnerabilities which is detected only when a known user logs into the portal.
Defense in Depth
“Defense in depth” is defined as “an information assurance concept in which multiple layers of security controls (defense) are placed throughout an information technology system.” You need to identify your most sensitive services and manually apply many different security layers to them to get more challenging for a potential attacker who can exploit one of your security layers.
The goal of a defense-in-depth strategy is to prevent potential attackers from exploiting the entire application. If one microservice is exploited, the attacker, ideally, should not be able to move laterally to other services.
Practice Isolation
In a typical microservices-based application, you should be able to build, test, extend, deploy, and maintain the application in an isolated way, i.e., none of these activities should affect the functioning of any of the other microservices in the application.
You should implement isolation at the database level as well. This means that each microservice should have its copy of data and should not be able to access the data pertaining to the other microservices in the application. By implementing isolation at all layers, you can make your microservices-based application more secure.
Container Security
Microservices more often than not, rely on container technology. Therefore, securing containers is one way to reduce the attack surface and risks. NIST publishes guidance on securing microservices and containers.
- NIST Special Publication 800-204, Security Strategies for Microservices-based Application Systems (and its parts SP 800-204A to 800-204D)
- NIST Special Publication 800-190,Application Container Security Guide
- NISTIR 8176, Security Assurance Requirements for Linux Application Container Deployments
Namely, some practices to secure your containers are:
- Create immutable containers
- Run images from trusted sources only
- Secure access to images with a registry
Scan Dependencies
More than often, many libraries used to develop software depend on other third-party libraries. These relatioships might pose vulnerabilities for your systems. You should regularly scan an application’s source code repository, new code contributions, and deployment pipeline for vulnerable dependencies.
Use Access and Identity Tokens
In microservices deployment, a large number of applications and services will require secure authorization and access control. An authorization framework such as the OAuth 2.0 and OpenID enables you to process the tokens securely, hence protect your microservices.
OAuth 2.0 is a widely used standard for delegated authorization; for user authentication, use OpenID Connect, which is built on top of it. Although there are several other authorization protocols, and you can also build your own, it is best practice to use the OAuth since is more standard, stable, and widely accepted.
Encrypt and Protect Secrets
API keys, secrets and credentials used for communication should be protected. Do not store them in your source control system. Encrypt them using tools like Microsoft Azure Key Vault and Amazon KMS. This approach ensures the keys needed to decrypt any data are always unique and safe.
Use Rootless Mode
Docker 19.03+ has a rootless mode that was designed to reduce the security footprint of the Docker daemon and expose Docker capabilities to systems where users cannot gain root privileges. If you are running Docker daemons in production, this feature adds an extra layer of security.
Time Based Security
Time-based security assumes that a system is never fully secure. In addition to preventing intruders from entering the system, detection and reaction are essential for securing a system.
Client Traffic Rate Limiting
Limiting the external traffic prevent issues such as denial of service (DoS) attacks as well as instances where some clients consume most of the application bandwidth.
You can rate limit using the API gateway, through the code, or any other technique. Usually, most of the SaaS environments have API rate limiting to minimize abuse by users as well as attacks.
Use API Gateways
In a typical microservices-based application the service consumers are not able to communicate with the microservices directly. An API Gateway is used that provides a single point of entry for directing traffic to various microservices.
This way the clients don’t have any direct access to the services and cannot exploit the services. If your API Gateway is placed behind the firewall, you can add a layer of protection around the attack surface.
An API gateway gives you one place to enforce authentication, rate limiting and input validation for external traffic. It does not secure traffic between services: authenticate and encrypt service-to-service calls as well (for example with mutual TLS through a service mesh), so that one compromised service cannot freely call the others. API Gateways are usually secured using token-based authentication.
Monitor Your Systems and Services
Since microservices rely on distributed systems, you need to have a reliable and effective monitoring strategy for all the individual components. Deploying continuous monitoring allows you to detect and address security risks in a timely manner.
Correction, 26 October 2026: this article said placing the API gateway behind a firewall secures all the microservices in an application, but service-to-service traffic must also be authenticated and encrypted; it listed draft NIST SP 800-180 among official standards, but that draft was never finalized, and NIST’s microservices guidance is SP 800-204; and it called OAuth a user identity strategy, but OAuth 2.0 is an authorization framework, and OpenID Connect provides user authentication.