IA-9 service identification and authentication requirements

What IA-9 service identification and authentication asks for

IA-9 requires the system to uniquely identify and authenticate defined system services and applications before they establish communications with devices, users or other services. No SP 800-53B baseline selects IA-9 at the low, moderate or high level or in the privacy baseline, so it applies only when your organization tailors a baseline to add it or adopts an overlay that includes it. If a team has been asked whether IA-9 applies to its internal APIs and workloads, the first step is to check the baseline and overlays the system is accredited against, then decide whether the organization-defined parameter for IA-9 should be set to cover those services. Both numbered enhancements, IA-9(1) and IA-9(2), are withdrawn in Release 5.2.0, so the base control stands alone and there are no enhancements to scope.

The risk IA-9 addresses is a service that impersonates another service or connects without being verified. A payment API that accepts calls from any process on the network, or a batch job that writes to a database under a shared account, can be spoofed or can pass forged data along a trust chain nobody checked. Without service identities, audit logs show a generic address or a shared credential rather than the component that acted, which weakens investigation after an incident. Digital certificates, workload identities issued by an internal certificate authority, and mutual TLS are common mechanisms, but the control does not name a technology, so the choice has to be documented and defensible.

Two decisions usually make IA-9 hard. The first is defining which services count. Teams should inventory system services, daemons, APIs, scheduled jobs and application-to-application connections, then record which of them the organization's parameter covers. The second is proving that authentication happens before communication, not after. Assessors using SP 800-53A will look for the security safeguards that identify and authenticate services, the audit records that show it, and a test that a service without a valid identity is refused. Confirm with your assessor which evidence format they expect before you build the test plan.

Which services and teams IA-9 reaches once you tailor it in

IA-9 has no SP 800-53B baseline selection, so the organization sets its reach through the organization-defined parameter and the tailoring record. The cards below cover the decisions that most change the evidence an assessor will ask for, and each one should be written down with its rationale.

Defining the services in the ODP

IA-9 contains one organization-defined parameter that names the system services and applications requiring unique identification and authentication. Scope it by naming the services, not by describing a category such as internal APIs. A list an assessor can check against the system inventory is what makes the control testable. Confirm the list with the system owner and record the date and approver.

Service-to-service calls

Calls between microservices, internal APIs and message brokers are the most common reach of IA-9. Decide whether every such call must present a service identity, or only calls that cross a trust boundary. Each decision needs a traceable reason, because an assessor will sample calls and check whether the identity was verified before the connection was established.

Workload-to-database connections

Application servers connecting to databases, caches and object stores present service credentials that are often shared or static. Decide whether these connections are in scope and whether they authenticate with a certificate tied to the workload. Document the database platforms covered, since the assessor will test the safeguards on each one.

CI/CD and automation integrations

Pipeline runners, deployment tools and automation accounts act as services that call production systems. Decide whether they are defined as services under the ODP and how their identities are issued and revoked. Keep the secret detection and pipeline records with the scope decision, so the reviewer can see that the identities used by builds are covered.

Ownership of service identities

Each defined service needs a named owner who requests, rotates and retires its identity. Without ownership, certificates and service accounts persist after the workload is decommissioned. Write the owning team for each service class into the tailoring record, and confirm that the owners know their obligations under the control.

Third-party and SaaS services

Decide whether outside services that the system calls, such as payment gateways or hosted analytics, are defined services, and whether the organization or the provider authenticates them. Where the provider controls the identity, record that dependency and the contractual evidence the organization holds. This boundary often determines whether the scope is defensible at assessment.

How an assessor tests IA-9 with examine, interview and test

This table shows how an SP 800-53A assessor works through the single IA-9 determination statement, one row per assessment method and object type. Read each row as the question the assessor asks, the evidence to have ready, and the gap that most often stops a control from passing.

Method and objects	Test approach	Evidence to prepare	Common finding
Examine: safeguards and audit records	Compare the organization-defined service identification and authentication parameter (IA-09_ODP) against the documented service inventory and the mechanisms configured for each service	Service inventory, the value chosen for the IA-09_ODP parameter, certificate or credential configuration, and audit records of service authentication events	Parameter value is undefined or does not match the services actually running
Interview: operations personnel	Ask how services are named, issued credentials and checked before they communicate, and how a new service is added to the defined set	Named owners for each service, the onboarding procedure and the people who approve new service identities	Staff describe shared or default service accounts that no one owns
Interview: system and network administrators	Ask how service identity is verified at connection time and how a compromised or retired service identity is revoked	Revocation runbook, certificate or credential rotation records and network configuration showing where service authentication is enforced	Administrators cannot explain how identities are verified at connection time
Test: service identification and authentication safeguards	Attempt communication between defined services with and without valid service credentials and confirm that unauthenticated connections fail	Test results from each defined service pair, configuration snapshots and logs showing rejected unauthenticated attempts	Some service-to-service paths accept connections with no identity check
Test: certificate issuance and expiry handling	Confirm that issued service certificates or credentials are bound to the intended service and expire or rotate as configured	Issuance logs, certificate inventory with subject names and expiry dates, and rotation test records	Certificates are issued to a shared name that does not identify one service

Implementing IA-9 in order, from service inventory to rotation

This sequence turns IA-9 from a policy sentence into a working service identity process: every in-scope service has a documented identity, a verification point, logged outcomes and a defined way to rotate and revoke it. Each step leaves a record that an assessor can examine, interview against and test.

Inventory and define the services in scope
The system owner and platform engineering team list every system service and application that communicates with devices, users or other services, including schedulers, APIs, message brokers, database clients and internal microservices. Each entry records the owning team, the hosts it runs on, its communication partners and the data it handles. The output is a signed service register, approved by the system owner, that defines the population IA-9 applies to. Ask the assessor to confirm the register matches the boundary in the system security plan.
Set the organization-defined parameter values
IA-9 contains one organization-defined parameter, which the organization must assign a value to when it implements the control. The security office and system owner decide which services the parameter covers, and document the chosen values with the rationale for each. The output is a short parameter record linked to the service register. An assessor will compare the documented values with the system security plan and check that the implemented services match them.
Choose the identity mechanism
The team selects how each service proves its identity. Digital certificates issued by an internal certificate authority are a common choice because they bind a unique identity to a key pair and can be verified by any receiving service that trusts the authority. Alternatives include mutual TLS with managed identities or service tokens issued by an identity provider. The output is a design record that names the mechanism, the issuing authority, the trust chain and the cryptographic algorithms. Confirm with your key management and FIPS-validation requirements before finalizing the design.
Configure services to present their identities
Engineers configure each service in the register to present its identity before it opens a connection. Open-source options include FreeIPA, which includes an integrated certificate authority based on Dogtag for issuing and managing certificates, and OpenBao, whose PKI secrets engine issues dynamic X.509 certificates so services do not need to generate keys and certificate signing requests by hand. The output is a configuration baseline per service type, stored in version control, with change records for each deployment. Tests should show that an unidentified connection attempt is refused.
Enforce verification at the receiving side
Authentication only means something if the receiving service checks the presented identity before it accepts traffic. Engineers configure each listener or API gateway to validate the certificate chain, the validity period, the intended name and the revocation status, and to reject services that fail any check. The output is a test report showing accepted and rejected connection attempts for representative services, including expired, untrusted and mismatched identities. Assessors typically test this step directly, so the test evidence should be retained with the assessment package.
Log authentication outcomes
Each successful and failed service authentication produces an audit record that identifies the service, the receiving system, the time and the outcome. The security operations team forwards these records to the central log platform under the organization's audit retention rules and reviews failures on a defined schedule. The output is a sample of audit records for each service class, plus the review procedure that shows who looks at them and what action follows. Confirm that the log content meets the audit requirements in the organization's own audit policy.
Set rotation and revocation procedures
The organization documents how service certificates are renewed before expiry, how compromised or decommissioned identities are revoked, and how revocation reaches every receiving service in time to matter. Automated issuance, such as short-lived certificates from a PKI secrets engine, reduces manual steps, but the procedure still needs an owner, a trigger for emergency revocation and a test. The output is the approved rotation and revocation procedure, a record of at least one rotation and one revocation exercise, and the register updated with each change. Ask the assessor which exercise evidence they expect to see.

Evidence that passes an IA-9 test and how to keep it current

IA-9 is not in any SP 800-53B baseline, so an assessor will first look for proof that the organization selected it on purpose and defined the services it covers. The cards below cover the artifacts that connect that selection to working service identities, and how each one stays accurate between assessments.

Tailored baseline or overlay showing selection

Because SP 800-53B does not select IA-9 for the low, moderate or high baselines or the privacy baseline, the file that adds it is the first thing an assessor checks. Keep the tailoring record or overlay that lists IA-9, the reason it was added, and the approver. Each time the baseline is revised, confirm IA-9 is still present and that the record matches the release of SP 800-53 the system was assessed against. Ask your assessor which format they accept, such as a signed document or an OSCAL profile.

Service register with parameter values

IA-9 has one organization-defined parameter, so the register must state which services and applications the organization has defined as requiring identification and authentication. List each service, its owner, its identity type and the parameter value it falls under. Review the register on a fixed schedule and whenever a service is added, retired or moved. An assessor who finds a running service missing from the register will question the whole control.

Configuration exports showing identity requirements

Assessors want to see that services actually refuse connections without a valid identity. Export the relevant settings from each service, such as TLS client authentication requirements, mutual TLS listener configuration or service account bindings, and store them with the date and host. Regenerate the exports after every change window, and compare them with the previous set so unexpected drift is visible. Export output alone does not prove enforcement, so pair it with a test showing a connection without an identity is rejected.

Certificate issuance and revocation records

Where services authenticate with X.509 certificates, the issuance log, the revocation list and the renewal history show that identities are created, rotated and withdrawn under control. Confirm that each certificate maps to a register entry and that revoked certificates were removed from service. Open-source certificate authorities such as those in FreeIPA or the OpenBao PKI secrets engine can produce these records, but confirm the retention and export options in your own environment. Review a sample of issuance and revocation events each quarter.

Audit records of service authentication

Logs of successful and failed service authentication show the control operating over time, and failed attempts show that the check is real. Confirm that the audit configuration captures authentication events for every register entry, that logs are protected from change, and that someone reviews failures on a set cadence. Map log sources to register entries so an assessor can trace a sampled service from its identity to its authentication history. Ask your assessor how long they expect these records to be kept.

System security plan entry

The system security and privacy plan must describe how IA-9 is implemented for this system, including the services in scope, the identity mechanism used for each, and who operates it. Write the entry in terms of the actual register and configuration, not general intent. Update the plan whenever the register changes or the implementation method changes, and check that the plan, the register and the exports all name the same services and mechanisms. Mismatches between these documents are a common reason an assessor records a finding.

What IA-9 costs when self-hosted tools carry the license spend

This table separates the cost components of meeting IA-9 for service identities into one-time and recurring work, and shows which ones self-hosted open source can reduce. Read it as a list of what to price separately: license spend can fall toward zero, while engineering, evidence and review effort remain. No supplied figures exist for these components, so use the questions in each row to request a written quote.

Cost component	One-time or recurring, and who is paid	What drives it up or down	Effect of self-hosted open source
Tooling or licenses	Recurring if commercial. The organization pays the vendor; open-source software carries no license fee, though support contracts may be optional.	Number of identity services, environments and certificate authorities. Ask whether the quote includes vendor support tiers.	Can remove license spend for components such as FreeIPA, OpenBao and GitLab Community Edition, subject to confirming each feature in your environment.
Engineering time to configure service identities	One-time for initial design and rollout, then recurring for new services. The organization or its implementation partner is paid.	Count of services that need identities, variety of runtimes, and team familiarity with PKI. Ask the partner to scope by service inventory.	Does not remove effort. Open-source tools still require design of naming, issuance workflows and integration with each application.
Certificate lifetime and rotation operations	Recurring. Staff time or automation runs continuously after go-live.	Certificate lifetimes, automation coverage and the number of manual renewals. Shorter lifetimes increase automation needs.	Automated issuance, such as dynamic X.509 certificates from a PKI secrets engine, can lower manual work, but automation must be built and tested.
Evidence upkeep	Recurring. The organization owns the evidence; a partner may prepare documentation or reports.	Frequency of evidence collection, number of systems in scope and how much is captured automatically from logs and pipelines.	Self-hosted tools can generate logs and reports, but the organization must confirm which records satisfy the assessment objects for IA-9.
External testing or review	Recurring or periodic. The organization pays a tester or reviewer; only an independent assessor issues assessment conclusions.	Scope of service identity testing, number of trust boundaries and whether tests include certificate misuse or impersonation.	Open-source tools do not replace independent testing. Ask the tester how service identity cases will be covered and reported.
Auditor or assessor sampling	Recurring at each assessment cycle. The organization pays the assessor according to its engagement terms.	Number of services sampled, depth of examination and availability of consistent evidence. Ask the assessor for its sampling approach before scoping.	Consistent, system-generated records can reduce sampling friction, but the assessor determines the sample and conclusions.

Which open-source tools can produce IA-9 evidence

IA-9 asks for service identities that are uniquely identified and authenticated before services communicate, so the evidence has to show where those identities come from, how certificates are issued, and whether credentials leak into code. The three tools below each cover one part of that chain, and each leaves a gap the organization must close with its own design and records.

FreeIPA certificate authority

FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag for issuing and managing certificates. For IA-9, it can serve as the issuer of certificates that bind a service or application to a unique identity, and its issuance and revocation logs can show who requested and approved each certificate. The gap is the service identity design itself: you must decide which services get identities, how their names map to certificates, and how revocation is triggered when a service is retired. Confirm that its certificate profiles and enrollment workflow fit your service inventory before relying on it as evidence.

OpenBao dynamic X.509 certificates

The PKI secrets engine in OpenBao (MPL-2.0) issues dynamic X.509 certificates, so a service receives a certificate without an operator generating a key and certificate signing request by hand and waiting for a CA to sign it. This matters for IA-9 because short-lived, machine-issued identities are easier to show as consistently applied than manual certificates. The gap is policy: you still define the roles, allowed names, time-to-live values and which systems may request them, and you must keep the audit records that show each issuance. Confirm the engine's current capabilities and your key storage requirements in the project documentation before you commit to it.

GitLab pipeline secret detection report

Pipeline secret detection in GitLab Community Edition (MIT) scans files committed and pushed to the repository in a CI/CD job, and it writes findings to a gl-secret-detection-report.json job artifact in every tier. For IA-9, that artifact supports the claim that service credentials are not hardcoded into source, which would otherwise let a service identity be impersonated. The gap is coverage and response: the scanner reports only what it can detect, so you must define scan triggers, review and triage steps, and rotation of any exposed credential. Confirm the detection rules and the artifact retention in your pipeline configuration, since these are yours to set.

Your team, an implementation partner and the auditor for IA-9

Your organization owns IA-9. Under the control, the system must uniquely identify and authenticate the services and applications you define before they communicate with devices, users or other services. Deciding which services are in scope, what identity each one carries and how strong that identity must be are management decisions that cannot be handed to anyone else. Your team also sets the organization-defined parameter for the control and accepts the residual risk when a service cannot meet it.

Service inventory: Maintain the list of system services and applications that need identities, with owners and the systems they support.
Parameter values: Decide and document the values for the organization-defined parameter, and record why they were chosen.
Risk decisions: Accept, mitigate or plan remediation for services that cannot yet authenticate, through your risk management process.
Policy and procedures: Approve the procedures that govern how service identities are requested, issued, renewed and revoked.
Operational ownership: Staff the people who answer assessor interviews about how service identity works day to day.

Before engaging any partner or assessor, confirm internally that you can name the owner of each service identity and the person who signed off on the risk decision.

Where IA-9 implementations usually fall short

IA-9 is short, but the gaps around it are predictable: the control is never scoped in, the services it covers are never named, and the credentials behind those services are issued and then forgotten. Each card below names one gap, why it matters for IA-9 Service identification and authentication, and a check the reader can run.

Control never selected or documented

IA-9 is not in any SP 800-53B baseline, so teams often assume it does not apply and never record a decision about it. Check the system security and privacy plan and any tailoring worksheet or overlay for an explicit entry for IA-9, either selecting it or documenting why it is out of scope. A silent omission is the gap an assessor is most likely to question, because the organization cannot show it considered service identity at all.

Services never defined

IA-9 requires identification and authentication for *defined* system services and applications, and the organization must assign values to that parameter. When the list is empty, the requirement is met on paper and missed in practice. Build an inventory of service accounts, daemons, API clients and inter-service callers, then record that inventory as the value for the IA-9 parameter in the control implementation statement. Confirm each entry has an owner and a named consumer.

Certificates issued but never rotated

Service certificates are often issued once during deployment and then left to expire, or to remain valid long after the workload is retired. Revocation and rotation are what keep service identity meaningful. Ask for the issuance log, the expiry date of every service certificate, and the procedure for revoking a certificate when a service is decommissioned. Automated issuance, such as the dynamic X.509 certificates from the OpenBao PKI secrets engine, shortens the window in which a stale certificate stays trusted.

Authentication failures not logged

A service that rejects a peer's certificate or token produces a failure that is useful evidence, both for detecting impersonation and for proving the control operates. Many platforms log successful connections but drop failed handshakes at default verbosity. Confirm that the identity provider, certificate authority and reverse proxies write failed service authentication attempts to the central audit store, with timestamps and the presented identity. Test this by deliberately presenting an invalid certificate in a non-production environment and checking the record.

Hard-coded secrets bypass identity

When a service authenticates with a password or API key embedded in source code or configuration, the design defined for service identity is bypassed entirely. The credential cannot be rotated without a code change and is often shared across environments. Run secret detection in the pipeline on every commit and push, for example with the pipeline secret detection job in GitLab Community Edition, which writes findings to a report artifact. Review each finding and confirm the replacement is an issued identity, not a new static secret.

Services running as personal accounts

A service that authenticates as a named engineer's user account inherits that person's password resets, departures, access changes and multi-factor settings. Its activity also becomes indistinguishable from the person's own. Check the identity inventory for service entries that map to human accounts, and confirm each service has its own non-person identity with an accountable owner. An illustrative test: disable the owner's account in staging and see whether any service stops working, which reveals the dependency.

What buyers ask before bringing in help with IA-9

Does IA-9 still apply if no SP 800-53B baseline selects it?

Yes, it applies whenever your organization adopts IA-9, but no baseline requires it by default. SP 800-53B Release 5.2.0 does not select IA-9 for the low, moderate or high baselines or the privacy baseline. Your system's authorizing official, contract, or agency may still require it through tailoring or an overlay, so check the security plan and the contract language before deciding. If it is selected, the control becomes an assessed requirement like any other, and the assessor will test it against the SP 800-53A procedure. Ask the authorizing official to confirm in writing whether IA-9 is in scope for your system.

How much effort does IA-9 take, and what drives it?

The effort depends mainly on how many service-to-service and application-to-service connections you have and how many of them already authenticate with unique identities. NIST does not estimate compliance costs, so no general figure is available from that source. The main drivers are the number of defined services, whether they use certificates, secrets or shared credentials today, the state of the certificate authority, and how much evidence the assessor expects. Cost is mostly staff time for inventory, design, configuration and testing, plus any licensing or hosting of the certificate or identity tools you choose. Ask any provider for a quote built from a written list of services and connections.

Can our team implement IA-9 alone with open-source tools?

Often yes, if the team has skills in PKI, identity management and CI/CD, and the scope is limited. Open-source options exist for the parts IA-9 needs. FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates. OpenBao's PKI secrets engine can issue dynamic X.509 certificates to services. GitLab Community Edition runs pipeline secret detection that can flag hard-coded credentials. The harder work is the design: deciding which services get identities, how they are named, how keys are protected and how the evidence is collected. Confirm each tool's current capabilities with its project documentation before you commit to a design.

How long does IA-9 work take, and what does it depend on?

NIST does not set implementation timelines for SP 800-53, and this page does not supply a duration. The schedule depends on the number of services in scope, the maturity of your existing identity and PKI setup, change windows for production systems, and how quickly the owners of each service can test changes. Approval cycles and the assessment date also matter, since the evidence must be current when the assessor tests it. Ask for a schedule that lists phases, dependencies, and the staff each phase needs, and treat any fixed date without that breakdown with caution.

What does IA-9 require from our own staff?

Your staff keep ownership of the control. The organization must decide which services and applications are defined for IA-9, approve the identity and certificate policy, and accept the residual risk. Engineers who run those services must take part in identifying them, configuring their identities and testing that communication fails when identity is missing. Security and operations staff provide access to logs and the certificate authority, and must be able to explain the design to an assessor. Interviews are part of the assessment, so the people who run the services should be available to answer questions about their configuration.

What does a fixed-scope DeployOpen engagement cover for IA-9?

A fixed-scope engagement is agreed in writing before work starts and sets out scope, deliverables and timelines. For IA-9, DeployOpen can plan and implement self-hosted open-source platforms inside your own infrastructure, including certificate and secret issuance services, integration with your existing services, hardening, backup and documentation. It can also prepare the configuration and evidence an assessor will review. The written scope should name the defined services, the platforms in use, the environments covered and the deliverables. DeployOpen does not set the control's requirements for your organization and does not decide the parameter values for IA-9.

Can DeployOpen issue the IA-9 assessment report?

No. DeployOpen prepares systems, controls and evidence for an assessment, but it does not issue audit reports, attestations or certifications. The assessment is performed by an independent assessor or the authorizing organization's assessment team, under the process your agency or contract requires. Your assessor will use the SP 800-53A procedure for IA-9, which includes one determination statement and the examine, interview and test methods. Ask your assessor which evidence they expect, and agree with them early which systems and services will be sampled.

How DeployOpen scopes and prepares IA-9 evidence

DeployOpen works on IA-9 as a scoped implementation task: we define which system services and applications need unique identities, build the identity mechanisms inside your infrastructure, and prepare the evidence an assessor will examine, interview and test. The organization keeps ownership of the control, and only an independent assessor issues any conclusion about it.

How we scope

We list the services and applications in your environment that communicate with devices, users or other services and need unique identities.
We confirm with you the organization-defined parameter for IA-9 and which baseline or overlay, if any, selects the control.
Fixed-scope engagements record the services covered, deliverables and timelines in writing before work starts.

How we build

We configure service identity mechanisms such as digital certificates, using a certificate authority you choose and operate in your environment.
Candidate platforms include FreeIPA, which includes an integrated Dogtag-based certificate authority, and OpenBao's PKI secrets engine for dynamic X.509 certificates.
We test that each defined service authenticates before it establishes communications, and we document the failure behavior we observe.

How we hand over

We deliver a service inventory, configuration records, certificate issuance and renewal procedures, and the safeguard documentation an assessor will examine.
We map the delivered evidence to the SP 800-53A examine, interview and test methods for IA-9, so your team and the assessor know where each item applies.
Your staff receive runbooks for certificate rotation, revocation and onboarding of new services.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work closes.
We can re-test service authentication after upgrades, new services or changes to the certificate authority.
Support scope, response expectations and any SLA are agreed in writing with the retainer, so you can confirm them before signing.