What IA-12 identity proofing asks for before an account exists
Before an account is granted for logical access, the organization has to know who is behind it. IA-12 asks for exactly that: users who need accounts are identity proofed to the identity assurance level set by the standards and guidelines that apply to the system, each identity is resolved to one unique individual, and identity evidence is collected, validated and verified. In practice, this means the organization decides what level of confidence it needs, checks the documents or records that support a person's claimed identity, and only then lets provisioning create the account. An account that is issued to the wrong person, or to a person who cannot be tied to a single identity, undermines every later control that relies on user attribution, from audit logs to least privilege.
SP 800-53B selects IA-12 for the moderate and high baselines but not for the privacy baseline, so the control is expected on systems where account misuse carries material impact. The enhancements add more depth: identity evidence (IA-12(2)), validation and verification of that evidence (IA-12(3)), and address confirmation (IA-12(5)) are selected in the moderate and high baselines, and in-person validation and verification (IA-12(4)) is added in the high baseline only. Confirm the baseline and the identity assurance level your system's authorizing official and applicable guidance require before scoping the work, because the depth of proofing for a contractor account and for a public-facing account can differ.
The hard part is that proofing is not an IT task alone. The evidence usually sits with HR, the people who grant access sit in help desk or provisioning, and the account lifecycle is run by identity tooling. Each handoff is a place where proofing can be skipped. Legacy accounts are the most common gap: they were created before any proofing rule existed, often by a manager's request, and nobody has traced them back to a verified person. Start by inventorying how accounts are created today, then decide which accounts need retroactive proofing and which new accounts must be blocked until proofing is recorded. Ask your team to show, for a sample of recent and legacy accounts, the proofing record that links each account to one individual.
Which accounts and teams IA-12 reaches in an IA-12 identity proofing scope
IA-12 applies to people who need accounts for logical access, so the scope depends on who holds those accounts, which system impact level selects the control and which identity assurance level applies. Each card below is a decision or boundary that changes how much proofing work your organization carries, and each one should be confirmed with your assessor before you size the effort.
Employee accounts
Employees who receive accounts for logical access are the most common population in an IA-12 scope. Identity proofing for this group usually runs through HR onboarding, where the organization collects identity evidence and links it to a single person before any account is created. Check whether rehires, transfers and name changes create new identities or update existing ones, because duplicate identities are the case IA-12 asks you to resolve to a unique individual.
Contractors and temporary staff
Contractors often receive accounts through a staffing firm or a sponsor inside the organization, which can leave the proofing step split between two parties. Decide which party collects and verifies identity evidence, and confirm that the contract requires it. Record who sponsored each account, since an assessor will ask how the organization knows a contractor's identity matches the person using the account.
Administrators and privileged accounts
Privileged administrators usually sit at the top of the risk ranking, so they are the first population to bring into scope and the last to tolerate weak proofing. Confirm whether the identity assurance level set for administrators is higher than for standard users, and whether break-glass or shared administrative accounts exist that cannot be tied to one person. Shared accounts are a common gap an assessor will flag under IA-12.
Partner and outside user accounts
Partners and members of the public who sign in to your systems may fall under IA-8 (non-organizational users) rather than IA-12. The boundary depends on whether the account grants logical access to your system and who the assurance requirements come from, so do not assume the split without checking it. Ask your assessor to confirm in writing which population sits under IA-12 and which sits under IA-8.
Impact level that selects IA-12
SP 800-53B selects IA-12 for the moderate and high security control baselines, so a system categorized at low impact does not carry IA-12 under the baseline. Confirm the categorization of each system in scope, because a shared identity platform that serves moderate and low systems usually takes the higher requirement. Document the categorization in the system security plan so the scope decision can be traced.
Privacy baseline and assurance level owner
The privacy baseline does not select IA-12, so a privacy-only obligation does not by itself bring this control into scope. The identity assurance level comes from the standards and guidelines that apply to your system, and the organization, its contracting authority or its regulator sets it. Get the assurance level in writing before you design the proofing process, since it determines how strong the evidence and verification must be.
How an assessor tests IA-12 identity proofing under SP 800-53A
This table maps the SP 800-53A approach for IA-12 to the assessment method, the objects an assessor examines, interviews or tests, the evidence to prepare and the findings that commonly appear. Read each row as one slice of the assessment, since the five determination statements are tested across all three methods together.
| Assessment method | Assessment objects | Evidence to prepare | Common findings |
|---|---|---|---|
| Examine (policy and procedures) | Identification and authentication policy and procedures addressing identity proofing | Written policy stating which identity assurance level applies to each user type, plus proofing procedures with owners and review dates | Assurance level is named in policy but never mapped to specific account types or systems |
| Examine (system security and privacy plans) | System security plan and privacy plan entries for identity proofing | Plan sections describing where proofing happens, who performs it and how identity evidence is handled | Plan describes proofing generically and does not match how accounts are actually created |
| Interview (system operations personnel) | Organizational personnel with system operations responsibilities | Walkthrough of how an account request moves from intake to verified identity, with the staff role at each step | Staff describe informal verification by email or phone that no procedure records |
| Interview (legal counsel) | Legal counsel consulted on identity requirements | Records of which laws, contracts or standards set the assurance level and how counsel confirmed them | Assurance requirements in contracts are not traced to the proofing process |
| Test (identity mechanisms) | Mechanisms supporting and implementing identification and authentication capabilities | Configuration exports and test accounts showing that proofing steps run before access is granted | Accounts can be activated before evidence is validated, or proofing is bypassed for bulk imports |
| Examine (identity evidence records) | Records of identity evidence collected, validated and verified for sampled users | Sampled proofing records showing evidence type, validation result, verifier and date for each unique individual | Records missing evidence, duplicate identities for one person or no verifier named |
| Test (address and in-person steps) | Address confirmation and in-person validation steps, where the organization has selected them | Test results showing address confirmation is attempted and that in-person checks are recorded where required | Enhancements are claimed as implemented but no test or record exists for them |
Implementing IA-12 identity proofing in seven steps
This sequence turns IA-12 from a policy statement into a proofing process that assigns each user population an identity assurance level, records every proofing decision, and links verified identities to the accounts that depend on them. Each step produces an artifact an external assessor can examine.
Set the identity assurance level per user population
Start by listing every population that needs a logical access account, such as workforce staff, contractors, administrators, partners and members of the public. For each population, identify the identity assurance level that applicable standards and guidelines require for the systems it reaches. IA-12 does not set the level itself, so the level must come from the law, contract or framework that governs the system. The output is a population-to-level register, signed off by the system owner and tied to the system security plan. The step is complete when every account type maps to exactly one level and the mapping has an owner.
Define the proofing procedure for each level
For each identity assurance level in the register, write the proofing procedure the organization will run. The procedure states who performs proofing, what contact or sponsor steps happen before an account request is approved, and what the reviewer must confirm before approving. Keep the procedure separate for each level so that a lower-assurance population is never proofed to a higher standard by accident, and vice versa. The output is a short, versioned procedure document with an owner and a review date. Confirm with counsel or the authorizing official that the procedure meets the level you selected.
Define accepted identity evidence and validation methods
Specify which identity evidence the organization accepts for each level, such as government-issued documents, employment records or existing verified credentials, and how each item is validated. Validation covers checks that the evidence is genuine and that it belongs to the person presenting it. Verification covers confirming the identity against an authoritative source. Record which checks are automated, which require a trained person and what happens when evidence does not match. The output is an evidence matrix that lists each accepted item, its validation method and its verification source. The step is complete when an assessor can trace any account back to the evidence class used.
Define address confirmation and in-person steps for high
For systems at the high baseline, define how the organization confirms the address of record and when it requires in-person validation and verification. SP 800-53B selects the address confirmation enhancement at the moderate and high baselines, and the in-person enhancement at the high baseline only, so the procedure must show these steps for high systems. Describe how the address is confirmed, such as a mailed code or a documented check against an authoritative record, and who performs the in-person session. The output is a documented sub-procedure that states which populations trigger these steps. The step is complete when the procedure shows the enhancement steps for every high-baseline population.
Connect proofing outcomes to account creation
Configure the directory or identity provider so that an account is created only after a proofing decision is recorded as approved. In a FreeIPA deployment, for example, the account creation workflow can be gated by a documented approval step, and access control and delegated administration limit who can create accounts. In authentik, SCIM provisioning can push user and group changes to target applications and deprovision users when they lose access, which keeps downstream systems aligned with the approved identity. Confirm these capabilities against the versions you run. The output is a configuration record and a test showing that an unapproved identity cannot obtain an account.
Record each proofing decision
Store a record for every proofing decision that names the individual or entity, the identity assurance level applied, the evidence classes presented, the validation and verification results, the address confirmation outcome where required, the approver and the date. Keep these records in a system with access control and retention rules that match the organization's policy. Records of rejected applications matter as much as approvals, because they show that the procedure was applied. The output is a proofing log that can be sampled. The step is complete when a sample of accounts can be traced to a complete decision record.
Run an internal assessment against the determination statements
Before an independent assessor examines IA-12, test the implementation yourself against the five determination statements in SP 800-53A Rev. 5. Use the examine method on the policy, the procedures addressing identity proofing, the system security plan and the privacy plan. Use interview on personnel who run system operations and on legal counsel where they shape the procedure. Use test on the mechanisms that support identification and authentication, such as the directory approval workflow. Document each finding, assign remediation owners and update the plan of action and milestones. Only the independent assessor issues an assessment result. The internal review produces the evidence and the gap list that the assessor will examine.
Which evidence satisfies IA-12 and how to keep it current
An assessor testing IA-12 looks for a chain of records: the policy and procedures, the assurance level assigned to each population, and the proofing and verification records behind each account. The cards below cover each artifact and how to refresh them between assessments, including sampling accounts created since the last review.
Identification and authentication policy and proofing procedures
The assessor starts with the identification and authentication policy and the procedures that address identity proofing. Check that the documents name who performs proofing, which identity assurance level applies, which identity evidence is accepted, and how exceptions are approved. Confirm the owner, the review date and the distribution list, and that the procedure matches what the proofing system actually does today. A policy that describes a manual process while accounts are created automatically will fail the examination.
Assurance level assignments per population
Record which identity assurance level applies to each population of users who need logical access, such as employees, contractors, administrators, partners and members of the public. IA-12 ties proofing to the level set by applicable standards and guidelines, so the assignment should cite the source that sets the level. Keep the mapping in the system security plan and review it when a new population or application is added.
Proofing records linking accounts to a unique individual
IA-12 requires each identity to resolve to a unique individual. Keep a record for every account that ties it to one person, the proofing date, the proofing operator and the evidence reference. Check for duplicate identities, shared accounts and accounts whose proofing record is missing. This record is the core evidence an assessor samples.
Identity evidence validation and verification records
The enhancements that cover identity evidence and its validation and verification require a record of what was collected, how it was checked and what the result was. Store the evidence type, the check performed, the result and the reviewer, and keep the evidence under restricted access with a defined retention period. Confirm the retention period with counsel and the privacy office, since identity documents carry personal data obligations.
Address confirmation and in-person verification logs
Address confirmation (IA-12(5)) needs records showing how the address was confirmed and when. For the high baseline, in-person validation and verification (IA-12(4)) needs logs of who was verified, by whom, and the documents presented. Keep these as separate records so an assessor can test each enhancement without reconstructing it from account data.
System security plan entries and identity provider configuration
The system security plan should describe how proofing is implemented, which system holds the proofing records, and which identity provider issues the resulting identities. Export the configuration of the directory and identity provider, including where identities are created and deprovisioned, and attach it to the plan. The plan must match the running configuration or the assessor will record a finding.
Refreshing evidence and sampling recent accounts
Between assessments, schedule a recurring review that pulls the accounts created in the last period, then tests each one against its proofing record, assurance level and evidence. Record the sample size, the selection method and the exceptions, and open a plan of action item for each gap. Ask the implementation partner to script this sampling so the evidence set can be regenerated on demand, and confirm that an independent assessor, not the partner, reaches the final conclusion.
What IA-12 identity proofing costs in money and effort
This table breaks down the cost components of meeting IA-12 identity proofing, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote and to see where open-source directories cut license spend without removing proofing labor.
| Cost component | One-time or recurring, who is paid | What drives it up or down | How to keep it down |
|---|---|---|---|
| Proofing staff time | Recurring. Internal staff or proofing team; any outside provider if contracted | Number of new accounts, number of user populations, and whether each population needs in-person checks | Group populations by assurance level, automate low-risk intake, and reserve manual review for exceptions |
| Third-party identity verification service fees | Recurring per transaction or per verification, paid to the vendor; confirm pricing model in writing | Volume of verifications, document types checked, and retries for failed checks | Verify only where the assurance level requires it, and confirm retry and re-verification terms before signing |
| Engineering time to connect proofing outcomes to provisioning | One-time build, then periodic maintenance. Internal engineers or implementation partner | Number of identity sources, how many systems consume the proofed status, and whether provisioning is automated | Connect one authoritative identity source first, then extend. Use directory and provisioning features already in the stack |
| Evidence upkeep | Recurring. Internal compliance or security staff | Number of populations, frequency of re-proofing, and how many records must be retained and retrievable | Store proofing outcomes and identity evidence references in a single system, with consistent retention rules |
| Backfilling existing records | One-time, large when present. Internal staff or contracted reviewers | Number of accounts created before proofing rules applied and the quality of existing identity data | Prioritize privileged and high-impact accounts first, and document a decision for records you cannot verify |
| External testing or review | Periodic. Independent testers or assessors, paid directly by the organization | Scope of the proofing workflow, number of integrated systems, and whether the review covers the vendor chain | Define the proofing scope in writing and test the workflow once per material change |
| Auditor or assessor sampling time | Recurring per assessment cycle. Independent assessor, not DeployOpen | Number of populations sampled and whether evidence is readily available for each sampled account | Keep a sampling-ready record per account and ask the assessor to confirm sample size before fieldwork |
| Open-source directory license spend | Avoided license cost for the directory itself, such as FreeIPA (GPL-3.0-or-later); labor and hosting remain | Hosting model, support contract choice, and staff skills in the chosen directory | Confirm license terms with the project, and budget for proofing labor, which the license does not remove |
Which open-source tools hold IA-12 evidence: authentik and FreeIPA
Identity proofing under IA-12 creates a record that has to connect to the account it authorizes. authentik and FreeIPA are two open-source options that hold the account side of that link, so their configuration and logs can show when accounts were created, changed and removed. Neither one proofs identities on its own.
authentik SCIM provisioning lifecycle
The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, and runs a full sync every hour. When a user loses access to an application, authentik deprovisions that user from the target. For IA-12, this lifecycle output is evidence that an account created after proofing is carried through to downstream systems and removed when access ends. Confirm that the proofing reference is stored as a user attribute so that each provisioned account can be traced back to its proofing record. Review the sync logs as part of your evidence set.
authentik licensing and scope
authentik is released under the MIT license, which generally allows internal use and modification without a copyleft obligation. The license does not change what the product does, though. Its SCIM provider handles account lifecycle, not identity verification. Document who on your side is responsible for the proofing step, what evidence it produces, and how that evidence is linked to the account authentik creates. Confirm the supported target applications for your environment before you rely on automatic deprovisioning for every system.
FreeIPA central identity store
FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. Access control and delegated administration are managed centrally through its web UI and command line tools. For IA-12, this gives you one authoritative place where a proofed identity becomes a unique directory entry. Check how each person is resolved to a single entry and whether duplicate or reused identities are blocked at creation. Keep administrator change records as part of the evidence trail.
FreeIPA licensing and proofing gap
FreeIPA is licensed under GPL-3.0-or-later. Internal use does not trigger distribution obligations, but if you distribute modified versions, the copyleft terms apply, so involve counsel where that is a possibility. FreeIPA stores identity data but does not collect or verify identity evidence. Confirm where enrollment records, document checks and in-person validation are captured, and how those records are referenced in the directory entry. Auditors will ask for this link directly, so document it before the assessment begins.
Proofing outside both tools
Neither authentik nor FreeIPA performs identity proofing, so the evidence for IA-12 has to come from a process outside these products. That process typically covers the intake of identity evidence, validation and verification, and address confirmation for higher baselines. Assign an owner for the process, define where records are kept, and set a reference that both the proofing system and the directory or identity provider can share. Ask any implementation partner to show how that reference flows into the account lifecycle.
Who does what for IA-12: your team, a partner and the auditor
Your organization owns IA-12 in full. Your policy and procedures must define which identity assurance level applies to each type of account that needs logical access, and someone accountable must make and document the proofing decisions. The control language leaves the assurance level to applicable standards and guidelines, so your compliance and risk owners decide which guidance you follow and record that choice in the system security plan.
- Assurance level decisions: Select the identity assurance level for employees, contractors, partners and customers, and record the rationale.
- Proofing decisions: Approve or reject identity evidence exceptions, including cases where a person cannot present standard documents.
- Identity evidence records: Retain what was collected, how it was validated and verified, and who signed off.
- Unique identity resolution: Confirm that duplicate or shared identities are detected and resolved to one individual.
- Enhancement scope: Decide whether in-person proofing (IA-12(4)) or address confirmation (IA-12(5)) applies to your system, based on its baseline and impact level.
Check that each of these decisions has a named owner and a dated record, because assessors will ask for them before they ask for technical settings.
An implementation partner can prepare the technical and documentary groundwork that makes IA-12 testable. Typical work covers the directory and provisioning integration that carries identity records between systems, evidence templates for proofing records, and an internal dry-run assessment that walks through the assessment objects before an external review. The partner works on systems and documents you own, and the decisions remain yours.
- Directory and provisioning integration: Connect your identity source to target applications, for example through SCIM provisioning in authentik or a directory such as FreeIPA with 389 Directory Server, so account creation and removal follow the approved identity record.
- Evidence templates: Build forms and logs that capture identity evidence, validation results and approvals in a consistent format.
- Internal dry run: Test the records against the examine, interview and test steps in SP 800-53A, and list gaps for your team to resolve.
- Remediation support: Help configure fixes and document them in the plan of action and milestones.
The partner cannot attest to IA-12, issue findings, or state that the control is met. Confirm in the statement of work that the partner's deliverables are preparation work and that they will not be presented as an assessment result.
An independent auditor, assessor or certification body is the only party that tests IA-12 for assurance and issues any report or finding. The assessor follows the SP 800-53A procedures, examining the identification and authentication policy, the procedures on identity proofing, the system security plan and the privacy plan. They interview personnel with system operations responsibilities and, where relevant, legal counsel, and they test the mechanisms that support proofing.
- Document examination: Review the policy, procedures and system security plan for consistency with the assurance level you chose.
- Personnel interviews: Ask operators how proofing happens in practice and how exceptions are escalated.
- Mechanism testing: Sample accounts and trace each one back to its identity evidence and approval.
- Determination: Decide whether each determination statement is satisfied, and document any finding.
- Independence: The assessor must be independent of the team that prepared the evidence, so ask how that separation is handled before engaging.
Confirm with your authorizing official or program owner which assessor is acceptable for your context, since requirements for assessors vary by program.
Responsibilities split differently depending on size, existing identity tooling and the authorizing body's expectations. The table below summarizes common patterns, and your own environment will shift these lines.
- Usually in-house: Assurance level selection, proofing decisions, approval of exceptions, identity evidence retention and sign-off of records.
- Often outsourced: Directory and provisioning integration, evidence template design and the internal dry-run assessment.
- Usually in-house with support: Ongoing operation of the identity provider, account reviews and removal of access when people leave.
- Always independent: Testing the control, reaching a determination and issuing any report or certificate.
- Recurring work: Re-checking records, reviewing exceptions and updating procedures as systems change.
Ask your partner and auditor to put their boundaries in writing before work starts, so that each party knows which records it produces and which it does not.
Where IA-12 identity proofing usually fails an assessment
IA-12 is rarely failed for missing technology. Assessors usually find a proofing process that exists in practice but was never written down, applied to every population, or recorded as evidence. The cards below cover the gaps that come up most often and the fix for each.
No written assurance level per population
Many organizations proof users without first deciding which identity assurance level applies to employees, contractors, customers and partners. IA-12 asks for proofing to the level set by the applicable standards and guidelines, so an assessor will look for a document that names the level for each user population and the reason for it. Check that every population has a named level in the system security plan. Without that record, the rest of the proofing process has no defined standard to meet.
Accounts created outside the proofing path
Help desk staff, onboarding scripts and manual directory edits often create accounts without any proofing step or record. The account exists, works and is never linked to a verified identity. Assessors test this by comparing directory creation logs against proofing records for a sample of accounts. Route every account creation, including scripted ones, through a step that writes a proofing record. Scripts should refuse to create an account whose record lacks a proofing reference.
Legacy accounts never backfilled
Accounts created before a proofing process existed often remain active with no identity evidence on file. Organizations tend to treat these as grandfathered, which an assessor may not accept for accounts that still grant logical access. Inventory accounts that predate the process and decide, per population, whether to re-proof, restrict or disable them. Record the decision and its date so the gap has a documented owner and closure.
Identity evidence without a validation method
Teams often collect a passport scan, a national ID number or a document upload but cannot say how it was checked. IA-12 requires identity evidence to be validated and verified, and an assessor will ask which method was used and who performed it. Write down the validation method for each evidence type the organization accepts. Keep the evidence reference and the result in the identity record so the check can be repeated during an audit.
Address confirmation missing where selected
The moderate and high baselines select address confirmation as an enhancement of IA-12, yet many proofing processes only collect an address and never confirm it. Assessors look for a defined confirmation method, such as a mailed code or a verified document, and a record that it happened. Confirm which baseline applies and implement the confirmation step for that population. Document the method so the assessor can trace it to the system.
In-person steps undocumented at high baseline
The high baseline selects in-person validation and verification as an IA-12 enhancement. Organizations often perform these steps at a branch, a registration desk or by a manager vouching in person, but leave no procedure or log. Write a procedure for in-person validation, define who may perform it and store a dated record for each instance. An undocumented in-person step is treated as a step that did not occur.
Contractor and partner accounts bypassing proofing
Accounts for contractors, vendors and partners are often provisioned by a sponsoring manager or pushed from an external system without passing through the same proofing path as employees. IA-12 applies to users who need accounts for logical access, which includes these populations. Map every source that can create an account, including federated and sync-based provisioning, and confirm each one enforces the same proofing requirement. Where a sync pushes accounts from an outside system, the proofing record should be created or referenced at the point of entry.
Questions buyers ask about IA-12 identity proofing cost, time and effort
How much effort does IA-12 identity proofing take to implement?
The effort depends on how many people need accounts for logical access, which identity assurance level your applicable standards set, and how many systems must accept the resulting identities. IA-12 asks you to identity proof users to that level, resolve each identity to a unique individual, and collect, validate and verify identity evidence. The work splits into process design (who proofs whom, with which documents, at which step), system changes (where proofing results are recorded and linked to accounts), and recurring operation (new joiners, contractors and re-proofing events). Enhancements IA-12(2), IA-12(3) and IA-12(5) add evidence, validation and address confirmation steps that multiply the effort. Ask any partner for a figure only in a written scope that lists the user populations, systems and enhancements covered.
How long does IA-12 preparation take, and what drives the timeline?
No duration is fixed by NIST, and NIST does not set implementation timelines for SP 800-53 programs, which it leaves to OMB Circular A-130 for federal agencies. The main drivers are the number of identity sources, whether an identity provider such as authentik or FreeIPA already holds user records, how much proofing evidence already exists in HR or onboarding files, and how long your policy approval and assessor scheduling take. Each enhancement you select, particularly the in-person validation in IA-12(4) required at the high baseline, adds process steps with their own lead times. Ask for a timeline in the written scope, with milestones for policy, process, system changes and the evidence package your assessor will request.
What does IA-12 require from our own staff?
Your own staff must own the decisions that an outside party cannot make for you. These include the identity assurance level your standards require, the proofing procedure your HR, security and legal teams accept, the documents you treat as valid evidence, and who is authorized to perform and approve proofing. Expect involvement from HR for employment records, IT for account creation, legal counsel for evidence retention and privacy, and the system owners who maintain the identity provider. The SP 800-53A assessment procedure for IA-12 includes interviews with personnel who operate the systems and with legal counsel, so those people must be available and able to explain the process.
Can we implement IA-12 ourselves without an outside partner?
Yes, an organization can implement IA-12 in-house if it has staff who understand the required identity assurance level, can configure its identity provider and can document the process. The work becomes harder when the proofing process must be designed from scratch, when several identity sources must be reconciled to one unique individual, or when the team lacks time to produce the evidence an assessor will sample. An implementation partner can prepare systems, configuration and evidence under a fixed-scope agreement, but DeployOpen and similar firms do not own your controls or issue assessment results. Compare an in-house estimate with at least one written scope before deciding.
Does IA-12 apply at the low baseline?
No, IA-12 is not selected at the low baseline. SP 800-53B Release 5.2.0 selects IA-12 for the moderate and high baselines, and it is not part of the privacy baseline. If your system is categorized at low impact, IA-12 is generally not required under the baseline, although the other IA controls you do need, such as IA-2 and IA-5, still apply. Confirm the baseline with the authorizing official or contract owner, because an agency, a contract or a tailoring decision can still add IA-12 to a low system.
Can an implementation partner issue an IA-12 attestation or certificate?
No. An implementation partner can prepare systems, procedures and evidence for IA-12, but only an independent assessor or the authorizing body that your framework names can issue findings, reports or authorizations. DeployOpen plans, configures and documents identity proofing workflows in your infrastructure and prepares the evidence an assessor will examine. Your organization owns the control and the risk decision, and the assessor forms the conclusion. Ask the assessor, not the implementer, which evidence formats and sampling approach they will accept before you commit to a scope.
How does IA-12 relate to IA-8 for outside users?
IA-12 covers identity proofing for users who need accounts for logical access, while IA-8 covers uniquely identifying and authenticating non-organizational users such as members of the public and partners. Both controls depend on a trustworthy identity, but IA-8 is about authenticating outside users at access time, and IA-12 is about establishing who they are before the account exists. Many organizations reuse a single proofing process for external and internal users, then document where IA-8 authentication applies. Confirm with your assessor whether the same evidence can satisfy both controls for the populations in scope.
How DeployOpen prepares IA-12 identity proofing evidence
DeployOpen plans, implements and documents the identity proofing workflow and the supporting systems for IA-12 inside your own infrastructure, using self-hosted open-source platforms. Your organization owns the identity assurance level and the control decisions, and an independent assessor tests the result.
How we scope
- Agree in writing which user populations and logical access paths fall under IA-12 and their required identity assurance level.
- Confirm the baseline (moderate or high) and which IA-12 enhancements apply to your system, with your compliance lead.
- Define the identity evidence sources, validation steps and address confirmation method you will document before work starts.
How we build
- Configure a self-hosted identity provider and directory so each person resolves to one unique identity record.
- Integrate proofing outcomes with account provisioning, for example by using authentik SCIM provider to push user changes to target applications.
- Test the workflow end to end and record results against the examine, interview and test methods in SP 800-53A.
How we hand over
- Deliver configuration documentation, the identity proofing procedure and mapped evidence artifacts for your assessor to examine.
- Provide an assessment-ready evidence pack with logs, configuration exports and test records tied to each IA-12 determination statement.
- Walk your team through operating the workflow so ownership of the controls stays with your organization.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask for a quote based on your written scope, including which parts remain with your internal team and which your assessor performs.
