What should organisations audit before they expand microservices further?

Why This Matters for Security Teams

Microservices expansion often fails for identity reasons long before it fails for scale. Every new service adds an identity, a credential source, an access path, and a revocation problem. If those elements are already fragmented, adding more services multiplies the blast radius and makes incident response slower. Current guidance from the NIST Cybersecurity Framework 2.0 and NHI Management Group’s Top 10 NHI Issues points to the same operational reality: visibility and control must come before growth. One NHI Mgmt Group stat illustrates the gap clearly: only 5.7% of organisations have full visibility into their service accounts.

That matters because service accounts, API keys, tokens, and certificates are not passive plumbing. They are privileged non-human identities that can be reused, copied, and over-scoped across environments. In practice, teams that expand first and audit later usually discover drift through outages, leaked secrets, or access reviews that do not match how services actually communicate.

How It Works in Practice

The audit should start with service identity inventory. Security teams need to know which services exist, which workloads own them, which credentials they use, and whether those credentials are unique or shared. That inventory should extend into service discovery, because discovery records often become the hidden control plane for lateral movement when they are stale or overly broad.

Next, review credential lifecycle controls. The question is not just whether secrets are stored in a vault, but whether rotation, issuance, and revocation are automated enough to keep pace with deployment frequency. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both emphasize lifecycle discipline: issuance, rotation, validation, and offboarding must be auditable, not improvised.

• Map each service to a unique identity and owner.
• Verify that credentials have defined TTLs and can be revoked centrally.
• Inspect access scopes for overreach across namespaces, clusters, and data stores.
• Check whether service discovery is restricted to intended consumers.
• Confirm logs can answer who accessed what, when, and under which identity.

From a governance perspective, this aligns with least privilege and traceability in the NIST framework, but the operational test is simpler: can the platform explain service-to-service trust without relying on tribal knowledge? These controls tend to break down when teams use shared secrets across environments because revocation becomes impossible without breaking unrelated services.

Common Variations and Edge Cases

Tighter identity and discovery control often increases deployment overhead, requiring organisations to balance release speed against revocation clarity. That tradeoff is real, especially in platform teams supporting many product squads. Best practice is evolving, but current guidance suggests that shared credentials, broad network trust, and ad hoc service registration should be treated as transition states, not permanent designs.

Legacy environments are the hardest edge case. Some services cannot be refactored quickly, and some message buses or sidecars still depend on long-lived credentials. In those cases, audit for compensating controls: segmented networks, vault-backed rotation, clear ownership, and alerting on anomalous access scope changes. Where service discovery is tightly coupled to ephemeral autoscaling, the risk shifts from stale records to blind spots, so audit coverage must include registration, deregistration, and stale endpoint cleanup.

Organisations should also watch third-party and internal platform dependencies. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks highlights that exposure often comes from overlooked trust paths rather than the primary application tier. The practical takeaway is that microservices growth should pause when identity ownership, rotation, and access review cannot keep up with service creation.

Related resources from NHI Mgmt Group

• What should organisations check before using cross-domain redirects?
• What should organisations check before moving critical services to IPv6?
• What should organisations measure when they build a context mesh?
• When should organisations prioritise Zero Standing Privilege for non-human identities?