Service-to-service authentication must be tested whenever internal components assume the network is trusted. The assessment should determine whether every workload has a verifiable identity, whether that identity is authorized for a narrow purpose, and whether direct routes, replayed tokens or compromised services can produce lateral movement beyond the intended call graph.

Define the architecture question before testing

The practical question is not simply whether mTLS or tokens exist. It is whether the receiving service can distinguish the permitted caller, intended operation and original user context from any other workload able to send traffic. Map who issues credentials, which claims survive each hop, where policy is enforced and how access is revoked.

Write the expected security invariant and the prohibited outcome in language that engineering, security and operations interpret the same way. Name the identity, trust transition, protected asset and authoritative state. That statement becomes the basis for scope, evidence and retesting.

Build the minimum evidence pack

  • A current component and trust-boundary diagram for the environment under test.
  • Identity, credential, network and data-flow details relevant to the decision.
  • Representative accounts, workloads and synthetic records with known ownership.
  • Logs or traces that follow the action through every material control point.
  • Explicit safety limits, stop conditions, owners and restoration steps.

Include service accounts, mesh policies, certificate issuers, token exchanges, gateway assertions, queue producers and non-HTTP paths. Record which routes bypass the mesh or gateway and which administrative or health interfaces rely only on network location.

Map workload identities and credential lifecycles

Inventory every caller and receiver in the critical service paths. For each credential, record issuer, subject, audience, scope, lifetime, storage, rotation, revocation and whether replicas share one identity. Shared long-lived credentials erase attribution and enlarge compromise blast radius.

  • Use a credential issued for one service against another receiver.
  • Test expired, rotated, revoked and not-yet-valid credentials.
  • Check whether cloned workloads inherit reusable secrets.
  • Verify development or staging identities cannot authenticate to production.
  • Confirm certificate identity is mapped to application authorization, not merely encryption.

Capture the receiver’s verified identity and policy result. A successful TLS channel proves encryption and possibly peer possession; it does not prove the peer may invoke the requested business capability.

Challenge direct and alternate routes

A gateway or mesh may add identity and policy on the expected path while a load balancer, node port, legacy hostname or administrative route reaches the service directly. Test agreed inventory routes rather than indiscriminate internal scanning.

  • Call the service without gateway-added identity context.
  • Vary host, protocol, port and versioned route.
  • Attempt access from a workload outside the permitted namespace or segment.
  • Check health, debug and management listeners for sensitive operations.
  • Verify queue and scheduled-job entry points authenticate producers.

Document the exact route and the control that accepted or rejected it. Network timeouts are not authorization evidence; confirm policy or application logs where possible.

Validate audience, scope and purpose

A technically valid token can still be wrong for the receiver or operation. Services should reject tokens issued to another audience, overly broad machine roles and user tokens repurposed as service credentials.

  • Replay a token intended for service A to service B.
  • Use read scope for a write or administrative operation.
  • Change tenant or resource identifiers while keeping the same workload token.
  • Test whether an internal super-scope silently bypasses object authorization.
  • Confirm delegated user context cannot be replaced by a stronger service identity.

Record both cryptographic validation and authorization outcome. Identify whether the receiver checks audience and scope itself or assumes an upstream component already did so.

Preserve actor and tenant context across hops

A downstream service may see only a trusted workload even when policy depends on the initiating user, tenant or purpose. Trace the original context and determine which claims are authoritative, signed and revalidated.

  • Remove or forge forwarded actor and tenant claims.
  • Use a legitimate service identity with a foreign object reference.
  • Revoke the initiating user before delayed processing.
  • Test confused-deputy paths where a low-privilege caller triggers a powerful service.
  • Check correlation and audit records preserve both actor and workload.

The authoritative object state must match the original caller’s rights. A service-to-service 200 response is insufficient when the delegated action violates user or tenant boundaries.

Assess compromise and lateral-movement bounds

Model one service as compromised without performing persistence or unrelated exploitation. Determine which credentials, destinations and actions its identity can reach, and whether policy follows the declared service call graph.

  • Compare allowed destinations with the architecture call graph.
  • Attempt a harmless operation outside the caller’s normal purpose.
  • Inspect whether credentials are exportable from the workload context.
  • Verify namespace or security-group boundaries complement identity policy.
  • Test emergency revocation and rotation in a controlled environment.

Report the minimum demonstrated reach and avoid speculative “full network compromise” claims. Distinguish network connectivity, successful authentication and authorized business effect.

Include failure, retry and recovery paths

Failover, dead-letter replay and operational bypasses often use different credentials or skip ordinary checks. Validate that resilience mechanisms preserve identity and least privilege.

  • Retry after credential rotation or revocation.
  • Inspect fallback endpoints and disaster-recovery routes.
  • Verify dead-letter replay authenticates the operator and producer context.
  • Test whether break-glass service identities are time-bound and audited.
  • Confirm degraded mode does not accept anonymous internal traffic.

Correlate the initial request, retry, credential used and final side effect. Security must survive recovery state, not only the steady-state path.

Execute as controlled hypotheses

  1. Establish the legitimate baseline and capture authoritative state.
  2. Change one trust variable—identity, route, scope, object, time or environment.
  3. Observe the decision at each layer rather than relying only on the response.
  4. Stop at the minimum proof that demonstrates or rejects the hypothesis.
  5. Restore test state and record residual uncertainty or blocked coverage.

Coordinate with platform operations so token tests and route checks do not trigger broad retries or availability controls. Use synthetic objects, conservative rates and identities created for the assessment. Never extract production secrets when an equivalent test credential can prove the policy result.

Report the architectural consequence

Connect every weakness to a failed trust assumption: missing workload authentication, reusable audience, absent receiving-service authorization, lost tenant context, direct-route bypass or excessive credential lifetime. Show the shortest safe path from the compromised caller to the protected effect.

Separate observed evidence from inference. State prerequisites, repeatability, blast radius and the shared component responsible for the decision. When multiple findings have one architectural cause, keep the individual proofs but group the remediation around the common control.

Required closure evidence

  • The original proof no longer succeeds.
  • A legitimate workflow still succeeds under the intended identity and route.
  • Alternate consumers of the same pattern enforce the same invariant.
  • Telemetry records both allowed and denied decisions with useful context.
  • The architecture record and threat assumptions reflect the new control.

Remediate at the durable control point

Adopt unique workload identities, short-lived credentials, receiver-validated audience and scope, explicit service authorization and policy-as-code aligned to the call graph. Restrict direct routes, bind delegated context cryptographically, centralize safe token exchange and make revocation observable. A mesh can distribute controls, but each sensitive receiver must fail closed when required context is absent.

Retest the invariant, not just the payload

Repeat the original route and token proof, then sample another receiver using the same identity library or mesh policy. Verify rotation, revocation, retries and delegated user context. Confirm legitimate calls continue to work without falling back to a broad shared credential.

Use the NIST Technical Guide to Information Security Testing and Assessment for assessment planning and evidence discipline, and the OWASP Web Security Testing Guide for relevant application techniques. Adapt both to the system-specific trust decision described here.

The architecture decision

Treat the internal network as transport, not authorization. The architecture is defensible when every sensitive receiver verifies a specific workload identity, narrows it to the intended audience and action, preserves user and tenant context where necessary, and limits lateral movement after one workload is compromised.

Ask WIMD to test east-west service trust across workload identities, direct routes, delegated context and lateral-movement boundaries.