IA-9 Service Identification and Authentication applies the identity idea to software talking to software. Uniquely identify and authenticate defined services before establishing communications with devices, users or other services or applications.
800-53 binds federal systems and contract holders. For others it is a reference, and it fits microservice and API heavy architectures well.
What it means in practice
NIST gives web applications using digital certificates and applications that query a database as examples. Methods include information or code signing, provenance graphs and electronic signatures that indicate the source of a service. The validity decision can be made by a separate service from the one being authenticated.
That points to mutual TLS, signed service tokens and workload identity systems. It also ties to supply chain concerns: knowing which build produced a service is part of identifying it.
Evidence to collect
- A service inventory with identity method per service.
- mTLS or token configuration for service to service calls.
- Certificate issuance and rotation records for workloads.
- Signing and provenance records for deployed artifacts.
- A test showing an unauthenticated service call is rejected.
Common gaps
Internal services that trust anything inside the network. Shared database credentials across many services. Certificates with multi year lifetimes.
The enhancements are IA-9.1 Information Exchange and IA-9.2 Transmission of Decisions.
How to implement it
Issue short lived workload identities, enforce mTLS between services, and give each service its own database credential.
Quick check
What are two methods NIST names for service identification?
Information or code signing, provenance graphs, or electronic signatures indicating the source of a service. Digital certificates are also given as an example for web applications.
