IA-8 Identification and authentication (non-organizational users)

What IA-8 requires for non-organizational users in NIST SP 800-53

IA-8 requires a system to uniquely identify and authenticate non-organizational users, or processes acting on their behalf, before they gain access. In NIST SP 800-53 Rev. 5, these are users outside the organizational population that IA-2 covers, such as members of the public, citizens, customers and partners. If your public, partner or citizen-facing system lets outside people sign in, IA-8 is the control that defines what your system must do to tell those people apart and check their identity. SP 800-53B selects IA-8 for the low, moderate and high baselines but not for the privacy baseline, so the control applies whenever a federal system or contract places one of those baselines on the system.

The control is hard in practice because the user population is large, varied and often self-registered. A single system may serve residents, business contacts, contractors and partner staff who each arrive from a different identity source, and each source may have its own sign-in strength. Start by listing every outside user population, how each one creates an account, which identity source vouches for it, and which authenticator it uses. Then confirm with the authorizing official which IA-8 enhancements apply. IA-8 has six numbered enhancements in Release 5.2.0, of which IA-8(3) is withdrawn, leaving five current enhancements. SP 800-53B selects IA-8(1) for accepting PIV credentials from other agencies, IA-8(2) for accepting external authenticators and IA-8(4) for using defined profiles at the low, moderate and high baselines.

Which outside users, systems and third parties fall under IA-8

IA-8 applies to people and systems outside the organization's own workforce, so the first job is deciding which external populations actually reach the system. The cards below separate the scoping decisions that change the work, from public access and partner access to federated identities, PIV acceptance, external authenticators and defined identity profiles. Confirm each decision against the system's impact level and its SP 800-53B baseline selection, because IA-8 and its enhancements are selected differently across the low, moderate and high baselines.

Public-facing applications

Members of the public who register or sign in to a public web or mobile service are the core case for IA-8. The system must uniquely identify each such user and authenticate them, and the assessor will look for account records that separate one person from another. Confirm whether self-registration creates accounts, whether anonymous access is limited to read-only content, and which identifiers the platform stores for each external user.

Partner and business portals

Vendors, contractors and business partners who sign in to a portal are non-organizational users even when a contract ties them to the organization. Each partner account should be tied to a named external entity so the organization can show who accessed what and when. Ask who approves partner accounts, how they are removed when a contract ends, and whether partner access is separated from workforce accounts.

Federated external identities

When an outside user signs in through a partner's identity provider or a social login, the organization still has to decide what it trusts about that identity. The enhancement IA-8(2) concerns accepting external authenticators, so the assessor will check which external identity providers are accepted and how their assertions are mapped to local accounts. Document the trusted provider list and the attributes the system relies on.

PIV credentials from other agencies

Enhancement IA-8(1) covers systems that accept Personal Identity Verification credentials issued by other federal agencies. It applies only where the organization chooses to accept those credentials, so the scope question is whether any external federal user will present one. Confirm which issuers are trusted, how certificate status is checked, and whether the acceptance decision is recorded in the system security plan.

Defined identity profiles

Enhancement IA-8(4) asks the organization to define the identity profiles that external users must meet, such as the assurance level or attributes required for a given role. Without a written profile, the assessor cannot tell whether a sign-in is acceptable. Ask for the profile definitions, who approved them, and how each application maps to a profile.

External authenticators and their strength

External authenticators, such as third-party authenticators or security keys issued outside the organization, bring their own strength and lifecycle. Where the system accepts them, the scope includes how they are validated and what happens when an external user loses one. Keycloak, Zitadel and similar platforms can enforce second factors, but the organization must decide which external authenticators it accepts and confirm this against the baseline it has selected.

How an assessor tests IA-8 under SP 800-53A

This table maps the single IA-8 determination statement in SP 800-53A Rev. 5 to the examine, interview and test methods an assessor uses, and to the suggested objects for each. Read each row as a question the assessor will ask, then check that your system can answer it with records.

Assessment element	What the assessor does	Suggested objects and evidence to prepare	Where it commonly fails
Determination statement	Confirms the system uniquely identifies and authenticates non-organizational users, or processes acting for them, before access is granted	Documented list of external user populations such as members of the public, partners and contractors, with the authentication path for each	Public or partner access exists but is not listed in the system security plan or inventory
Examine: list of system accounts	Reviews account listings to confirm each non-organizational account is unique and traceable to a defined population	Export of accounts from the identity provider, with account type, creation source and status fields	Shared or generic accounts used by partner integrations with no owner
Examine: system audit records	Checks that authentication events for non-organizational users are recorded and can be tied to one identity	Sample logs showing successful and failed sign-ins, token issuance and account lockouts for external users	Authentication events logged only at the application layer, or not logged at all for federated sign-ins
Interview: operations personnel	Asks how external users are onboarded, authenticated and removed, and who approves each path	Onboarding and offboarding procedure, approval records and a named owner for each external population	Staff describe the process from memory, and the procedure does not match what the system does
Interview: system and network administrators	Confirms how administrators configure identity providers, federation trust and external authenticators	Configuration exports or screenshots of identity provider settings, federation metadata and trusted client registrations	Administrators cannot explain which external identity sources are trusted or who can add one
Test: identification and authentication mechanisms	Attempts sign-in with representative external identities and checks that unique identifiers are issued and enforced	Test cases and results for each external sign-in path, including rejected invalid identities and disabled accounts	Test covers only the primary login page, not federated, API or partner entry points
Common finding: undocumented external populations	Identifies user groups that reach the system but are absent from the plan, inventory and access reviews	Reconciliation of identity provider groups against the system boundary and security plan	Self-service registration or legacy accounts discovered late in the assessment
Common finding: unlogged authentication events	Notes gaps where external sign-ins or failures cannot be traced to a specific identity	Log source inventory showing each identity provider, proxy and application that records sign-ins	Logs rotate or are forwarded without timestamps or user identifiers

Implementing IA-8 in the order an assessor will follow it

This sequence takes an organization from an unclear list of outside users to a configuration that an assessor can trace from each population to its identifiers, authenticators, logs and documented profiles. Each step ends with an artifact the assessor can ask to see.

Define non-organizational user populations and trust boundaries
The organization, usually through its system owner and security team, lists every group of users outside its workforce who reach the system, such as members of the public, partner staff, contractors on external accounts and other agencies' personnel. For each group, it records the purpose of access, the functions it may use, the systems it touches and the boundary where its identity is first established. The output is a population register that the assessor can compare against the system boundary in the system security and privacy plan. The step is complete when every population has a named owner and a documented trust boundary.
Select identity sources for each population
For each population, the organization decides how its members prove who they are: self-registration with the organization's own identity store, federation with a partner's identity provider, acceptance of PIV credentials issued by another agency under IA-8(1), or external authenticators under IA-8(2). The decision should be recorded with its reason, including which populations will not be allowed to use a given source. The output is an identity source decision record, reviewed by the system owner and approved by the authorizing official or the party who holds that authority. The step is complete when no population lacks an approved source.
Configure unique identifiers and authenticators per population
The platform team configures the identity provider so that every external user has a unique identifier that cannot be shared with another person, and each population has authenticators matched to its risk. Open-source identity providers such as authentik, Keycloak and Zitadel can separate user sources, federate external identity providers and enforce multi-factor policies, but the configuration choices belong to the organization, and the platform team should confirm the exact settings against the vendor documentation for the version it deploys. The output is configuration exports, such as realm or policy definitions, stored under change control. The step is complete when a sample of accounts from each population shows a unique identifier and the required authenticator type.
Map external authenticators and defined profiles
Where the organization uses IA-8(4), it defines the profiles that external users may use, such as the attributes, assurance expectations and authenticator types each profile requires. It then maps each profile to the identity source and configuration from the previous steps, so the assessor can see which profile applies to which population. This is also the point to confirm how external authenticators are validated and what the system does when one is rejected. The output is a defined profile document with a traceability table. The step is complete when every profile in use appears in that table and no population relies on an undocumented profile.
Enable authentication logging and review
The organization configures the identity provider and the systems behind it to record successful and failed authentication events for external users, including the identifier, source, time and authenticator type. A named reviewer checks these records on the schedule the organization sets in its procedures, and the review result is kept as a record. Assessors compare this step with the audit controls for the system and with IA-8 related controls such as AC-2 and AU-6. The output is a log sample, a review record and a description of the alerting rule for failed or unusual authentication. The step is complete when the sample shows events from each population and a review has been performed and signed.
Test each population against the configured controls
Testers, who may be internal staff or an independent party, run test cases for each population: an account from each source authenticates with the approved authenticator, a shared or duplicate identifier is rejected, a disallowed source is refused, and a failed external authenticator produces the logged event. The organization keeps a test record that lists the case, the expected result, the actual result and the evidence reference. SP 800-53A describes the examine, interview and test methods for IA-8, and the test record maps directly to the test objects for identification and authentication mechanisms. The output is a signed test record. The step is complete when every test case has a recorded result and any failure has a tracked remediation item.
Hand the evidence to the independent assessor
The organization assembles the population register, identity source decision record, configuration exports, defined profile document, log sample, review record and test record into one evidence package indexed to IA-8 and its enhancements. An implementation partner can help prepare this package, but the organization owns the control and the assessor decides what the evidence shows. The output is an indexed evidence package and a list of open items with owners. The step is complete when the system owner can explain each artifact and the assessor has confirmed the scope and access needed for interviews and testing.

Evidence that passes an IA-8 assessment

An assessor testing IA-8 looks for proof that non-organizational users are uniquely identified and authenticated, that the populations and profiles are defined, and that the mechanisms behave as documented. The cards below cover the artifacts that carry that proof and the review habits that keep them current between assessments. The organization owns the control, and the independent assessor decides whether the evidence is sufficient.

Identity provider configuration exports

Export the identity provider settings that govern external sign-in, including enabled sign-in methods, provider and client registrations, and the authentication flows applied to public users. Store each export with a date, the system version and the change ticket that approved it. An assessor compares these exports against what the system actually does during testing, so a configuration that drifted from the exported copy is a finding. Confirm the export format and what it omits with the platform documentation before you rely on it.

Defined external user populations and profiles

IA-8 depends on the organization defining which non-organizational users exist, such as members of the public, partners and contractors, and which authentication profile applies to each group. Keep a written register that names each population, its trust level, the identity source it uses and the owner who approved it. The register is the first document an assessor asks for because every other test traces back to it. Update it when a new partner or user group is onboarded.

Authentication and failure logs

Retain logs of successful and failed sign-ins for external users, with the user identifier, timestamp, authentication method and source. Failure records show whether lockout and rejection logic works, and success records show that each person was matched to a unique account. Send logs to a central store that the operations team cannot silently edit. Confirm with your platform team which events the identity provider emits by default and which need explicit logging configured.

Unique identification test records

Record tests that create two external accounts with similar attributes and show the system keeps them distinct, and that a second registration with an existing identifier is refused. Also test that a user cannot sign in as another external user by changing a case or format variant of a username. Save the test plan, the expected result, the actual result and the tester's name. These records map directly to the test method SP 800-53A lists for identification and authentication mechanisms.

PIV and external authenticator acceptance records

Where the organization accepts credentials issued by other agencies or external authenticators, keep the list of accepted credential types, the trust agreements or issuer criteria behind each one, and test results showing that unaccepted credentials are rejected. Treat each accepted issuer as a dated decision with an owner and a review date. Passkey, TOTP and WebAuthn settings belong in this set when they are the external authenticators. Confirm the enabled options against the vendor documentation for your version.

Review cadence and change records

Set a fixed schedule for reviewing the population register, accepted credential list, exports and sample logs, and record each review with the reviewer, date and any changes made. Tie reviews to events such as a new partner, a new identity source or a failed test. Between audits, the review log shows the control is operating rather than documented once. The assessor will ask who signed off on each review and what happened to any exception.

Self-hosted identity providers that can support IA-8 evidence

authentik is an identity provider released under the MIT license. Its documentation describes providers for OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy access, so applications can delegate sign-in to it instead of storing their own credentials. For IA-8, this matters when members of the public, partners or other outside users reach your applications, because the identity provider becomes the single place where their unique identity is established and checked. Evidence usually comes from the identity provider's configuration, its event logs and the list of applications bound to each provider.

Application delegation: Register each external-facing application as an OAuth2, OpenID Connect or SAML provider so sign-in is handled centrally.
Protocol coverage: Use LDAP, RADIUS or proxy providers for systems that cannot speak modern federation protocols.
Evidence of configuration: Export provider and application bindings to show which applications accept outside users.
Authentication events: Retain sign-in logs that record which identity authenticated to which application.

Confirm with the vendor whether authentik supports acceptance of PIV credentials from other agencies or external authenticators as IA-8 enhancements, since those features are not established in the facts available to this page.

What meeting IA-8 costs in money and effort

The cost of meeting IA-8 is driven less by the control itself than by the identity platform that carries it. IA-8 asks the system to uniquely identify and authenticate non-organizational users, such as members of the public and partners, so the largest cost decision is whether to license a commercial identity service or self-host an open-source identity provider such as authentik, Keycloak, Zitadel or FreeIPA inside your own infrastructure. A commercial service shifts most of the platform cost into recurring subscription fees. Self-hosting moves cost into engineering and operations time for installation, hardening, upgrades, backups and high availability, which recurs for as long as the platform runs. Confirm current licensing terms and any usage-based pricing with each vendor, since none of the figures here are supplied.

Engineering effort is usually spread across one-time and recurring work. One-time work includes federating each application with the identity provider, configuring sign-in flows, designing user onboarding and self-registration, and setting identity proofing or verification steps for external users where your risk assessment requires them. Recurring work includes onboarding new partner populations, reviewing enhancement settings such as accepted external authenticators and defined profiles, and keeping evidence current. Costs rise with the number of applications, the number of external populations, the diversity of authenticators you must accept, and any requirement to integrate with existing customer or partner directories.

Assessment and evidence work is a recurring cost that many budgets miss. Assessors test IA-8 by examining system account lists and audit records, interviewing administrators, and testing the identification and authentication mechanisms, so you should expect to keep those artifacts exportable and retained. An implementation partner can prepare configurations and evidence, and external testing of public-facing sign-in is a separate scope item. Independent auditors or assessors decide sampling and issue conclusions, and their fees are set by their own engagement terms. When requesting a quote, ask for written scope covering the applications and user populations in scope, the identity platform and its hosting model, the baseline and enhancements selected, the integrations and onboarding flows to be built, the evidence to be produced, handover and support terms, and which items are one-time versus retainer-based.

Where IA-8 implementations usually fall short

IA-8 is easy to document and hard to prove. The gaps below cluster around who the system actually lets in, how partners and federated users are represented, and whether the external authentication features an organization claims were ever exercised. Each card pairs a gap with the check that closes it.

External populations missing from the register

Members of the public, partner staff and contractors often sign in through a separate portal, a self-registration flow or a shared identity service that never appears in the system's user inventory. An assessor testing IA-8 will ask for the list of accounts the system actually accepts. Reconcile the identity provider's user store against the documented population, and record which non-organizational groups are permitted and under which terms.

Shared accounts used by partners

A partner organization may sign in with one generic login that several of its people use, which breaks the requirement to uniquely identify each non-organizational user or process acting on their behalf. Closure means issuing one identity per person or per integration client, with its own credential and revocation path. Confirm that each service account is tied to a named owner who can be shown on request.

Federation events that leave no record

When an external user signs in through a federated provider, the local system may log only that a session started, not which identity was asserted or which provider vouched for it. Authentication events from federated sign-ins should land in the same audit trail as local ones, with the subject identifier and the asserting provider. Test by signing in as an external user and confirming the record can be traced back to a specific person.

MFA applied unevenly across populations

Staff may be required to use a second factor while external users, who often carry more risk, are allowed password-only sign-in. The gap usually appears because the MFA policy was configured on the internal realm or organization only. Document the authenticator requirement for each non-organizational population and verify it against the policy the identity provider enforces, for example by testing a new external account from a clean session.

PIV and external authenticators assumed, not tested

IA-8(1) and IA-8(2) cover accepting other agencies' PIV credentials and external authenticators, and programs often claim these features because the product lists them. An assessor will ask for evidence that a credential from outside the organization actually authenticates and that unsupported credentials are refused. Keep a test record for each accepted credential type, covering a successful sign-in, a rejected sign-in and the logged result.

Defined profiles that exist only on paper

IA-8(4) expects the system to use defined identity profiles for non-organizational users, such as the assurance level or attribute set a relying application requires. Profiles frequently live in a policy document while the identity provider accepts any attribute set from a partner. Map each profile to a concrete client or group configuration and check that a user outside it is denied access to the protected application.

Who does what for IA-8: your team, a partner and the auditor

Your organization owns IA-8. Accountability for the control stays with you even when an implementation partner builds the identity platform, and an assessor will test your decisions, not the vendor's. The first job is defining the population: which non-organizational users (members of the public, partners, contractors who are not workforce members, and other outside parties) reach your systems, and what level of assurance each group needs. Those decisions feed the authentication requirements that the rest of the control depends on.

Population decisions: Document each category of non-organizational user, the systems they access and the data involved.
Authentication requirements: Decide which authenticators, identity sources and acceptance rules apply, including whether you accept PIV credentials from other agencies or external authenticators under the enhancements.
Risk acceptance: Record any category you deliberately exclude or treat differently, with the approver and the reason.
Ownership of evidence: Keep the system security and privacy plan, configuration records and access reviews current and under your control.

Before engaging anyone, confirm that your policy owner has signed off on the population and the authentication requirements, because a partner cannot settle those questions for you.

Questions buyers ask about IA-8 cost, effort and scope

How much effort does IA-8 take to implement?

The effort depends on how many non-organizational users reach your system, how they sign in today, and which IA-8 enhancements your system's baseline selects. IA-8 has five current enhancements in SP 800-53 Release 5.2.0, after IA-8(3) was withdrawn, but the base control and the enhancements selected for the low, moderate and high baselines are what your assessor will examine. Effort rises when you must onboard several identity sources, define user profiles, and produce logs that show external users are uniquely identified and authenticated. NIST does not estimate implementation effort, so ask your implementation partner and assessor to agree on the effort in writing against your actual scope before work starts.

Can we implement IA-8 in-house without outside help?

Yes, many organizations do this with internal staff, and outside help is optional. The work splits into configuring the identity provider and applications, writing the procedures and evidence, and having an independent assessor test the result. Your team owns the control. An implementation partner can prepare systems and evidence under a fixed-scope agreement, but only an independent assessor issues assessment results. Teams that already run an identity provider and have a clear list of external user populations usually need less outside help than teams building identity from scratch. Check the skills in your own team against the assessment procedure for IA-8 before deciding.

What does the work need from our team?

The work needs input from several roles, not only security engineers. Plan for the following:

Identity or platform engineers to configure the identity provider, sign-in flows and application connections
Application owners to confirm which external users access each system and how they authenticate
Security or compliance staff to define the procedures and collect evidence
System or network administrators to provide the mechanisms and logs that an assessor will interview and test

The assessment procedure for IA-8 includes interviews with organizational personnel who run system operations and with system and network administrators, so those people need time to explain the setup. Name an owner for each role before the engagement starts.

Does IA-8 apply to the privacy baseline?

No. SP 800-53B Release 5.2.0 selects IA-8 for the low, moderate and high security control baselines but not for the privacy baseline. If your system is scoped only to the privacy baseline, IA-8 is not a required control on that basis. Confirm your system's baseline selection with your authorizing official or compliance lead, because the applicable baseline depends on your system's impact level and on any overlays or tailoring decisions your organization has made. Keep the baseline decision in your system security plan so the assessor can trace it.

How do PIV and external authenticator enhancements change the scope?

The enhancements add specific requirements to the base control, so each one you select expands the work. IA-8(1) covers accepting PIV credentials issued by other agencies, IA-8(2) covers accepting external authenticators, and IA-8(4) covers using defined profiles. SP 800-53B Release 5.2.0 selects all three for the low, moderate and high baselines, so they usually belong in scope when IA-8 does. Accepting external credentials means you must define which sources you trust, how you validate them, and how you record them in logs. Each trust relationship adds configuration, testing and evidence. Ask your assessor to confirm the scope of each enhancement against your system before you agree on a fixed scope.

Which open-source tools can support IA-8 evidence?

Open-source identity providers can handle sign-in for external users and produce much of the evidence an assessor asks for. authentik can act as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Keycloak supports two-factor authentication with passkeys, recovery codes and one-time passwords. Zitadel login policies support TOTP, U2F security keys, passkeys and one-time passwords, and its Force MFA setting can require a second factor for every user or only for locally authenticated users. FreeIPA focuses on Linux and UNIX single sign-on through an MIT Kerberos KDC. Choose a tool based on the protocols your applications need, then confirm which features apply to your version and configuration.

What do we ask for in a quote for IA-8 work?

Ask for a written scope that names each external user population, each identity source, each application connection, and each IA-8 enhancement in scope. The quote should list the deliverables, such as configuration records, procedures, test results and evidence packages, and state who performs each task. Ask whether the price covers the independent assessment, which an implementation partner does not issue, and whether ongoing support or upgrades are separate. DeployOpen does not publish a price list, and a quote follows from the written scope. Request the assumptions behind the effort estimate so you can compare proposals on the same basis.

How DeployOpen scopes and prepares IA-8 evidence

DeployOpen plans, implements, hardens and documents the self-hosted identity platforms that handle non-organizational sign-in, inside the client's own cloud accounts, data centers or air-gapped networks, under a fixed scope agreed in writing before work starts. For IA-8, the scope conversation starts with a list of the populations that are not organizational users: members of the public, partners, contractors without directory accounts, and service consumers acting on their behalf. Each population needs its own answer to which identity provider it signs in through, which authenticators it accepts, and whether the platform accepts credentials issued by another agency. Those answers become the boundary of the work. The client owns the decisions. DeployOpen configures the platform to match them and records the result.

In practice, the candidate platforms named in the research (authentik, FreeIPA, Keycloak and Zitadel) differ in how they handle this population, so the scoping step should confirm which one fits the client's environment. Examples include whether applications delegate sign-in through OpenID Connect or SAML providers, whether the platform enforces second factors for external users through settings such as Zitadel's Force MFA or Keycloak's one-time password policies, and whether any PIV or other agency credential acceptance is required for IA-8(1). Where a capability is needed but not confirmed for the chosen product, the reader should verify it against current vendor documentation before it appears in the design. DeployOpen's deliverables typically include exported configuration, a record of the decisions taken, and test results that map to the IA-8 assessment objects in SP 800-53A.

Responsibility for the outcome stays divided. DeployOpen prepares systems, configuration and evidence. The organization owns its controls and signs off on the decisions. Only an independent assessor or auditor reviews the evidence and issues any report or determination. DeployOpen does not issue audit reports, attestations or certifications, and nothing in this engagement should be presented to an assessor as one. Before engaging a partner, ask for the written scope to name the external populations, the platform version and deployment location, the evidence list, and who performs each test. Ask for a clear statement of what remains with the client after handover, including the ongoing configuration review and the retention of logs for non-organizational sign-in attempts.