A company splits its monolithic e-commerce application into dozens of microservices that call one another through internal APIs. The architects previously relied on a perimeter firewall in front of the single application. Which security implication should they address FIRST in the new design?

Decomposing a monolith into microservices replaces in-process function calls with network calls between services. Each internal API becomes an entry point, so the attack surface grows and an attacker who compromises one service can try to move laterally by calling others. The design must therefore authenticate and authorize service-to-service traffic, commonly with mutual TLS or signed service tokens issued per service, and enforce least privilege on which services may call which endpoints. Relying solely on the perimeter firewall assumes anything inside is trustworthy; once one service is compromised, that assumption gives the attacker unrestricted internal access, which conflicts with zero trust principles. A single shared credential across all services destroys accountability and means one leaked secret compromises everything; per-service identities are needed so access can be scoped and revoked individually. Disabling logging on internal APIs removes the visibility required to detect lateral movement and to trace requests across many services, which is especially important in distributed architectures. Exam caveat: microservices improve fault isolation and scalability, but those benefits do not reduce the need for strong identity between components. Operational check: inventory every service-to-service call, issue distinct identities to each service, enforce mutual authentication and authorization policies at each endpoint, and centralize logs with request tracing.