IA-4 Identifier management: requirements and evidence

IA-4 identifier management: what the requirement asks for and why it is hard

When an audit, a contract or an authorizing official asks for IA-4 evidence, the question is whether your organization can show who authorized each identifier, that each one points to exactly one intended entity, and that identifiers are not handed to someone new while the old owner's access may still exist. IA-4 requires organizations to authorize identifier assignment, select and assign each identifier to its intended entity, and prevent reuse for a defined period. The control covers identifiers for individuals, groups, roles, services and devices, so a shared admin account, a forgotten service account or a reissued device name can each be a finding. Your organization owns the defined periods and the authorizing personnel; the assessor tests whether they are written down and followed.

Shared, orphaned or recycled identifiers cause most of the trouble. A shared login hides who did what, an orphaned account keeps access after its owner has left, and a recycled username can make an old audit trail point at a new person. The difficulty is usually structural: identifiers live in a corporate directory, in separate SaaS applications, in cloud IAM and in device inventories, and no single team owns the full list. Start by asking for an export of identifiers from each system and matching it against your HR and asset records. Confirm which team approves new identifiers and what the reuse waiting period is, because the assessor will ask for both.

SP 800-53B selects IA-4 for the low, moderate and high baselines, but not for the privacy baseline, so a system categorized at any impact level carries the base control. The moderate and high baselines also select IA-4(4), which concerns identifying user status, such as marking whether an identifier belongs to a contractor, a government employee or another category. Confirm your system's baseline with your authorizing official before you collect evidence, because the set of enhancements that applies depends on it. The SP 800-53A assessment expects examined lists of system accounts and identifier records, interviews with identifier management staff and tests of the mechanisms that enforce assignment.

Which systems, identities and teams fall under IA-4 scope

IA-4 scope is set less by the number of systems than by the identifier types they issue and the people or third parties who can create or change them. Each card below is a scoping question that changes the evidence an assessor will ask for. Confirm the impact level and baseline with your authorizing official or assessor before you fix the boundary.

Identifier types the system issues

IA-4 covers individual, group, role, service and device identifiers, so each type needs its own inventory line. Human user accounts are the obvious case, but shared group names, privileged role identifiers, service account names and device names all fall under the same requirement. List every identifier type the system creates, including those created automatically by integrations. Missing one type is a common reason an assessor finds gaps in the identifier register.

Directories that hold identifiers

Identifiers usually live in more than one place: a central directory, a cloud identity provider, local application databases and host operating systems. Each store that can create or retain an identifier is in scope for the assignment and reuse rules. Document which store is the authoritative source and how the others receive their copies. Where an application keeps its own user table, confirm whether it can issue identifiers independently of the directory.

Applications that receive provisioned identities

Downstream applications that receive user and group records from an identity source can create, change or retain identifiers on their own. Provisioning connectors determine whether a deleted identity is removed from those applications or left behind. Map each target application, the attributes it accepts and the event that triggers creation or removal. Open-source provisioning tools such as authentik's SCIM provider push creations, changes and deletions to targets and run a full sync every hour, which you should compare with your own reuse and removal requirements.

Internal teams with identifier authority

HR, the service desk, system administrators and application owners may each be able to create or modify identifiers. IA-4 requires that the assignment be authorized by defined personnel, so each team's authority must be written down and tied to a named approver. Record who may request a new identifier, who approves it and who executes the change. Overlapping authority between the service desk and an administrator is a frequent finding because neither side can show a clear approval trail.

Third parties that can create or change identifiers

Managed service providers, contractors and outsourced help desks often hold administrative rights that let them create accounts or rename identifiers. Their access sits inside your IA-4 boundary even when their staff are not your employees. Confirm which third parties can act on identifiers, under what contract terms and with what approval step. Require that their changes are logged and attributable to a named individual, not a shared operator account.

Baseline selection and identify user status

SP 800-53B selects IA-4 for the low, moderate and high baselines, so the control applies at every impact level that uses those baselines. The moderate and high baselines also select IA-4(4), identify user status, which asks you to manage individuals by their status, such as employee, contractor or other. Confirm the impact level with your authorizing official before setting scope, because the enhancement changes which user attributes must be tracked and reported.

How to implement IA-4 in sequence, with the output of each step

The sequence turns IA-4 from a policy statement into working identifier management: who may authorize each identifier, how identifiers are named and reused, which directory holds them, and how their status is checked. Each step leaves a document or configuration that an assessor can examine.

Define who may authorize each identifier type
Start by listing every identifier type in scope: individual user accounts, group accounts, role accounts, service identifiers and device identifiers. For each type, name the defined personnel who may approve its creation, such as a system owner, an HR-driven onboarding function or a platform team lead, and state what evidence of approval is kept. IA-4 requires authorization before assignment, so this matrix is the first thing an assessor will ask for. The output is an authorization matrix, approved by the control owner. The step is done when every identifier type has a named approver role and an approval record format.
Write naming and selection rules
Define how identifiers are selected and formed so that each one points to exactly one intended entity. Cover format, character set, prefixes that separate human, service and device identifiers, and rules for handling name collisions. Keep personal details out of identifiers where the organization's privacy rules require it. The output is a naming standard that engineering and administrators can apply without judgment calls. The step is done when a sample set of proposed identifiers can be checked against the standard and each one maps to a single entity.
Set the reuse-prevention period
IA-4 requires that identifiers not be reused for an organization-defined period, and the organization must set that value itself. Decide how long a retired identifier stays reserved, whether the period differs by identifier type, and what the reserved period is measured from, such as account disablement or deletion. Confirm the chosen value with the control owner and with any regulator or contract that sets its own expectations. The output is a documented reuse period written into the identifier management procedure. The step is done when the value is approved and the procedure states it in plain terms.
Choose the authoritative directory
Select the directory that is the source of truth for identifiers, and decide which systems consume it. Options include a central directory such as FreeIPA, which uses 389 Directory Server as a multi-master LDAPv3 store for users, groups and hosts with centralized access control, or an identity provider that federates to applications. Confirm each candidate's capabilities against your own environment, since support for specific object types and delegation models varies by product and version. The output is a directory configuration record covering object classes, delegated administrators and replication topology. The step is done when every identifier type in the matrix has one authoritative home.
Write the provisioning and deprovisioning runbook
Automate creation and removal from the authoritative source of personnel and service events, such as HR onboarding and offboarding records or change tickets for service accounts. Where a downstream application needs its own copy of an identifier, configure provisioning to push changes to it. For example, the authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users when they lose access. Test the behavior against your applications, because sync intervals and deprovisioning depend on the connector. The output is a provisioning runbook with trigger, owner, expected result and failure handling for each path. The step is done when a test identifier can be created, changed and removed end to end with logs kept.
Record retired identifiers in a reuse register
Apply the reuse period from step three to every deactivated or deleted identifier. Keep a reuse register that records the identifier, the entity it belonged to, the retirement date, the end of the reserved period and the approver of any early release. Link entries to the deprovisioning events from the runbook so the register updates automatically where possible. The output is the reuse register, which an assessor can use to confirm that no identifier was reassigned inside the reserved period. The step is done when a sample of retired identifiers can be traced to their register entry and reserved period.
Set up identity status checks for moderate and high baselines
IA-4 enhancement (4), which covers identifying user status, is selected in the moderate and high baselines in SP 800-53B. Define how the system determines whether a user is an employee, contractor, service or other category, and make that status visible to administrators and to access decisions. Set checks that flag accounts whose status no longer matches the authorization record, such as a contractor past end date. The output is a status check configuration and a report of exceptions with a named reviewer. The step is done when the status attribute is present on every user in the directory and an exception report has been run and reviewed at least once.
Run an assessment against the procedures
Before an independent assessor arrives, test IA-4 against the four determination statements and the examine, interview and test methods in SP 800-53A. Examine the authorization matrix, naming standard, reuse register and directory configuration. Interview the personnel who manage identifiers. Test the mechanisms by creating and retiring a sample identifier. Record gaps in a plan of action and milestones. The output is an internal assessment worksheet and any remediation entries. Note that the organization owns the control and its evidence, and only an independent assessor issues the formal assessment result. The step is done when every determination statement has evidence or a logged gap.

How an assessor tests IA-4 and what they ask to see

This table maps the SP 800-53A Rev. 5 assessment approach for IA-4 to the methods, evidence and gaps an assessor typically encounters. Read each row as one slice of the assessment, since the assessor combines examine, interview and test results before deciding whether each determination statement is satisfied. The main takeaway is that identifier management is judged on operating records, not only on a written policy.

Assessment element	Evidence requested	Common findings
Determination statement: authorization to assign identifiers	Documented list of personnel authorized to approve identifier assignment, and records showing approvals for recent individual, group, role, service and device identifiers	Approvals are missing for service or device identifiers, or the authorizing role is not defined in the procedure
Determination statement: selection and assignment to the intended entity	Account creation tickets or workflow records tied to a named person, service or device, and the directory entries they produced	Shared or generic identifiers created without a documented owner, or identifiers assigned to the wrong entity after a role change
Determination statement: prevention of reuse for a defined period	The organization's defined reuse period, directory settings or procedures that block reuse, and examples of attempted reuse being refused	The reuse period is not defined in the system security plan, or deleted identifiers can be recreated immediately
Determination statement: review of identifier status	Inventory of system accounts with status, the review cadence and sign-off records, plus any identifiers generated from physical access control devices	Inactive or orphaned accounts appear in the list of system accounts with no owner or disable date
Examine: list of system accounts and identifier lists	Exports from the directory or identity provider, with timestamps and the query used to produce them	Exports are edited by hand or do not match the live directory when the assessor samples them
Interview: identifier management personnel and system or network administrators	Named interviewees, their responsibilities and a consistent account of the assignment and reuse process	Administrators describe a process that differs from the documented procedure or from what the tool enforces
Test: mechanisms that implement identifier management	Live demonstration or configuration evidence from the directory, identity provider or provisioning connector, such as attempted creation of a reused identifier	Controls exist in documentation but are not enforced by the system, or provisioning and deprovisioning are not logged

Evidence that passes IA-4 and how to keep it current between audits

An assessor testing IA-4 looks for records that show how identifiers were authorized, assigned, kept unique and retired, and for proof that those records describe the system as it runs today. The cards below cover the artifacts that carry that proof, how to refresh each one on a schedule, and who should sign it off before an assessment begins.

Identifier authorization matrix

This matrix lists which defined personnel may authorize each identifier type (individual, group, role, service and device) and the approval path that leads to assignment. IA-4 requires authorization before assignment, so the matrix is the first document an assessor reads. Review it against the current directory roles each quarter and after any reorganization. Ask the control owner, usually the identity or access management lead, to sign each revision and to confirm that approvers named in the matrix still hold those roles.

Directory exports with creation dates

A scheduled export of accounts and groups from the directory, including creation dates and identifier types, shows what exists and when it was created. Assessors compare this export with the approval tickets to find identifiers that appeared without authorization. FreeIPA and other LDAP-backed directories can produce these exports from the command line, so the export job can be scripted and its output stored with a timestamp. Confirm that the export captures service and device objects, not only human accounts.

Identifier naming standard

A written naming standard defines the format for user, group, role, service and device identifiers, such as prefixes that show the identifier type or the owning system. It helps the assessor confirm that identifiers are selected in a consistent way and that a name clearly maps to one intended entity. Review the standard when new platform types are added and check a sample of live names against it. Record the exceptions and who approved them, because undocumented exceptions are a common finding.

Reuse prevention records

IA-4 asks the organization to prevent reuse of an identifier for a defined period, so the organization needs a record of retired identifiers and the dates they became unavailable. A tombstone list or a retention field in the directory can serve this purpose if it survives deletion. Confirm the retention period with the organization's own policy, since the period is a defined parameter that the organization sets. Test the control by attempting to recreate a retired identifier and keeping the result.

Deprovisioning tickets and SCIM sync logs

When an identity leaves an application, the removal should be traceable through a ticket or an automated sync log. For example, 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, so its logs can show when a target account was removed. Keep the sync logs for the period the assessor samples, and reconcile a sample against the source directory each cycle. Note that a sync log shows the mechanism worked, not that every application was covered, so keep an application inventory alongside it.

Sample approval tickets before assignment

For each sampled identifier, keep the request, the approver's sign-off and the assignment record, with the approval timestamp earlier than the creation timestamp. Assessors pick samples from the directory export and trace them back to approval, so the tickets must be easy to locate by identifier. Review a random sample each month, and confirm that the approver was an authorized person under the matrix at the time of approval. Screenshots taken once are weak evidence, so generate the sample from the live system and file it on a fixed schedule.

What meeting IA-4 costs in money and effort

This table breaks the cost of meeting IA-4 into components, showing who is paid, whether each cost is one-time or recurring, what drives it, and how to reduce it. NIST does not estimate compliance costs, so no figures appear here; use the table to structure a written quote and compare bids on the same scope.

Cost component	One-time or recurring	What drives it	How to reduce it
Licenses or tooling	Recurring if commercial, none for open source	Number of identity sources, directories and target applications, and whether vendor support is bought	Self-hosted open-source platforms such as authentik or FreeIPA can remove license spend, but infrastructure and staff time remain; confirm feature fit in writing
Engineering time for provisioning and naming rules	One-time build, with recurring changes	Number of identifier types (users, groups, roles, services, devices), reuse-prevention periods and HR or directory integrations	Define the naming convention and reuse period in policy first, then configure once and reuse the pattern across applications
Authorization workflow setup	One-time build, recurring operation	Number of defined personnel who approve identifier assignment and how approvals are recorded	Use existing ticketing or identity workflows that already log approvals, rather than building a new approval path
Infrastructure to host the identity platform	Recurring	High availability needs, number of sites, backup and recovery design, and environment count (test, production)	Size for the systems that actually need central identifiers; confirm sizing with the vendor or implementation partner
Evidence upkeep	Recurring	Frequency of identifier reviews, number of reports exported for assessors, and how many manual steps remain	Automate exports of account lists and identifier records so the same report can be reproduced on request
External testing or review	Recurring or per engagement	Scope of identity testing, number of applications and whether a third party reviews configuration	Limit scope to identifier paths first, then expand; get the testing scope and deliverables fixed in writing
Auditor or assessor sampling effort	Recurring with each assessment cycle	Number of identifiers sampled, quality of records, and whether reuse history can be shown for the defined period	Keep identifier history and deprovisioning records queryable so samples can be pulled quickly; ask the assessor which samples they will request

How open-source identity tools can produce IA-4 evidence

IA-4 evidence comes from records showing who authorized each identifier, how it was assigned, and what happened to it when a person or service left. Directory and provisioning tools can generate much of that record automatically, but the organization still owns the policy and must confirm that each tool's configuration actually enforces it.

authentik SCIM provisioning records

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. Deprovisioning happens when a user loses access to the application, so the sync and deprovisioning logs can show when an identifier was created in a downstream system and when it was removed. Confirm that the sync logs are retained for the period your assessor will sample, and that the identifiers in target applications map to the intended individuals. Check that a deprovisioned identifier is not reissued to someone else within the reuse period your policy defines.

FreeIPA central identifier store

FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. Because identifiers for these objects live in one directory, you can export the user, group and host lists as examine evidence for the list of system accounts that IA-4 assessors commonly request. Centralized access control and delegated administration also show who is permitted to create identifiers. Confirm that your configuration records which administrator created each identifier and that the directory retains deleted entries for the reuse window you have defined.

Delegated authorization for identifier creation

IA-4 requires authorization from defined personnel before an identifier is assigned. In FreeIPA, delegated administration can limit which administrative roles may create users, groups and hosts, and that delegation is the artifact an assessor will ask to see. Confirm that the roles you delegate match the personnel named in your identifier management procedure, and that the approval step for new identifiers is recorded somewhere outside the directory, such as a ticket or request system, because the directory alone may not show who approved an assignment.

Reuse prevention and status checks

Two IA-4 requirements, preventing reuse for a defined period and identifying user status, are not solved by the directory or provisioning tool by default. You must set the reuse period in your policy and then configure your tools to honor it, for example by keeping disabled accounts and their identifiers reserved. Confirm with your administrators how disabled, expired and terminated identities are handled, and collect evidence that a status check ran, such as a periodic review report. The enhancement for identifying user status applies at the moderate and high baselines, so a reviewer will look for this evidence first at those levels.

Who does what for IA-4: your team, an implementation partner and the auditor

Your organization owns IA-4 in full. The control asks for authorization before an identifier is assigned, a deliberate choice of identifier for the intended entity, and a defined period during which identifiers cannot be reused. Those decisions are business and risk decisions, so they belong to people accountable for the system, not to a contractor. Your team also owns the controls themselves, the policy that records them and the operating evidence that proves they run.

Authorization decisions: Name the personnel who approve creation of individual, group, role, service and device identifiers, and keep those approvals on record.
Naming and selection rules: Decide the identifier convention, such as how user names are built and how shared or service identifiers are distinguished from personal ones.
Reuse period: Set the defined period during which a retired identifier cannot be reissued, and document the reason for the number you chose.
Status process: Own the process that disables or retires identifiers, including the triggers from HR, contractors and offboarding, which feeds the identify-user-status enhancement.
Control ownership: Maintain the system security plan entry, the policy and the assessment responses that describe how IA-4 is implemented.

Before engaging anyone, confirm internally who holds each decision and whether those names appear in your documentation.

Where organizations fall short on IA-4 and how to close each gap

Most IA-4 findings come from identifiers that exist outside the directory of record, or from processes that nobody owns end to end. The cards below cover the gaps assessors most often raise, the fix for each, and the artifact that shows the fix is working rather than merely configured.

No defined authorizer for some identifiers

IA-4 requires that defined personnel authorize identifier assignment before it happens. Organizations often define this for employee accounts but not for service accounts, device names or shared mailboxes, which get created by whoever needs them. Name an authorizer for each identifier type in the identifier management procedure, and record who holds that role. The artifact is a signed authorization matrix plus a sample of recent identifier requests showing an approval before creation.

Shared or generic accounts created outside the directory

Local accounts on servers, appliances and SaaS tenants often bypass the central directory, so no one can tie them to a named owner. Inventory these accounts against the directory of record, and either bring them under central identity management or document the named entity responsible for each. Check whether generic names such as admin or svc-backup map to a person or a service. The artifact is a reconciled account inventory showing each identifier linked to an authorized entity.

No documented reuse period

IA-4 asks the organization to prevent reuse of identifiers for a defined period, so a departed employee's username cannot be given to a new hire and inherit old access history. Many organizations never define that period, or set it in one system but not others. Write the period into the identifier procedure, then confirm that the directory or provisioning tool enforces it. The artifact is the approved reuse period, the configuration that enforces it, and a test showing a retired identifier is rejected.

Orphaned accounts after offboarding

When a person leaves, accounts in downstream applications often remain active because deprovisioning only reaches the primary directory. Those orphaned identifiers keep their identity, which weakens the link between an identifier and its intended entity. Confirm that deprovisioning propagates to each connected application, and review accounts that have no matching active person. Self-hosted provisioning tools such as the authentik SCIM provider can push deletions to target applications, but the reconciliation review still has to be run. The artifact is a deprovisioning log and an orphan-account report with dispositions.

Service and device identifiers managed by no one

Service accounts, workload identities and device names are often created during deployments and then left without an owner. IA-4 applies to these identifiers as much as to people, so each one needs an assigned entity and an authorizer. Build an owner field into the asset or CMDB record and reject identifiers that lack one. Directory platforms such as FreeIPA can hold hosts and service principals centrally, which makes ownership easier to report. The artifact is a register of service and device identifiers with a named owner for each.

Evidence that shows configuration but not operation

Screenshots of a directory policy show how the system is set up, but an assessor will also want proof that identifiers were assigned, reviewed and retired as the procedure says. Sample real identifier lifecycle events across the period under review, including a request, an approval, an assignment, a reuse attempt and a retirement. Confirm the examine, interview and test methods in SP 800-53A are each covered. The artifact is an event sample with timestamps and approvals, plus interview notes from the personnel who administer identifiers.

IA-4 questions buyers and practitioners ask before hiring help

How much does it cost to meet IA-4 identifier management?

No public source gives a price for IA-4, and NIST says it does not estimate compliance costs, so treat any figure you see with caution. The cost has four parts: internal staff time to define identifier rules and approvals, engineering time to connect directories and provisioning flows, a partner's fixed-scope fee if you hire one, and the recurring time to review account lists and reports. The biggest drivers are the number of identity sources (directories, HR systems, cloud tenants), how many entity types need identifiers (people, groups, roles, services, devices), and how much history you must reconcile. Ask any provider for a written scope that lists these items separately, with one-time and recurring costs shown apart.

How long does IA-4 identifier management work take?

The duration depends on how many directories and identifier sources you have and how far integration must reach, so no general timeline applies. A single directory with a clear naming standard is a much smaller job than several directories that must be merged and tied to HR records. NIST does not set implementation timelines for federal systems either, leaving that to OMB Circular A-130. Ask for the timeline in the written scope, with milestones for the naming policy, the authorization workflow, the directory changes and the first evidence review, and confirm which of these depend on your own approvals.

What does the organization need to provide for IA-4 work?

The organization must supply the decisions and access that no outside party can make on its behalf. Named owners are needed for each identifier type, along with the people who authorize new identifiers and decide how long a retired identifier is blocked from reuse. Engineers need read and change access to the relevant directories, such as an LDAP or identity provider, plus the account and group lists. HR or the system of record must confirm who is employed, contracted or leaving, because that data drives reuse and deprovisioning. Agree on these owners and access paths before the scope is signed.

Can a small team implement IA-4 without outside help?

A small team with directory administration skills can often do the core work internally, especially if the environment has one directory and few identifier types. The harder parts are usually the authorization workflow, the reuse rules and the evidence trail, because they touch policy and records as well as technology. Open-source directories such as FreeIPA, which uses 389 Directory Server to store users, groups, hosts and other network objects, provide central management and delegated administration, so the platform itself is not the main obstacle. Decide honestly whether your staff has time for the policy, testing and evidence work alongside daily operations.

How does IA-4 evidence differ from IA-2 and IA-5 evidence?

IA-4 evidence shows how identifiers are created, approved, assigned and retired, while IA-2 evidence shows that users actually prove who they are at sign-in, and IA-5 evidence shows how the secrets and credentials used in that proof are issued, changed and protected. For IA-4, an assessor typically looks at the list of system accounts, the approval records for new identifiers, and the rules that block reuse for a defined period. For IA-2, the focus is authentication configuration and test results, and for IA-5, it is credential lifecycle records. The three controls share an identity source, so connect their evidence rather than collecting it separately.

Can a partner give us a NIST SP 800-53 compliance certificate for IA-4?

No. A partner such as DeployOpen can plan, configure and document the identifier controls and prepare the evidence, but it cannot issue audit reports, attestations or certifications. Those come only from independent assessors or certification bodies, and for federal systems the authorizing official makes the risk decision. Your organization still owns its controls. Before you hire anyone, confirm with the assessor or authorizing body which evidence they will accept and how they want it packaged, because that determines what a partner should deliver.

What should a request for quote include for IA-4 work?

A useful request for quote states the scope in writing before any price is discussed. Include the directories and identity sources in scope, the identifier types (users, groups, roles, services, devices), the systems that consume identifiers, and the assessment target your auditor or authorizing body uses. Ask the provider to list deliverables, such as the identifier naming and reuse standard, configuration changes, test results and an evidence map to IA-4, plus what the organization must provide. Request separate one-time and recurring costs, the assumptions behind the timeline, and the exclusions, including any work on the assessment itself.

How DeployOpen scopes, implements and prepares IA-4 evidence

DeployOpen works on IA-4 Identifier management as part of a written, fixed scope inside your own infrastructure. We prepare the identifier lifecycle, its configuration and the records an assessor will ask for, while your organization keeps ownership of the control and the independent assessor issues any conclusion.

How we scope

Confirm which systems, directories and identity sources issue user, group, role, service and device identifiers in scope for IA-4.
Record who in your organization authorizes identifier assignment, as IA-4 requires, and agree that approver list in writing.
Agree in writing whether the identify-user-status enhancement applies to your moderate or high baseline, and which systems must report status.

How we build

Configure identifier creation, naming and assignment rules in the self-hosted directory so each identifier maps to one intended entity.
Set the defined reuse-prevention period in the directory or provisioning workflow and test that retired identifiers cannot be reassigned early.
Connect provisioning to target applications so user status changes propagate, for example through SCIM-based sync where the chosen platform supports it.

How we hand over

Deliver a written identifier management procedure that maps each determination statement in SP 800-53A to a configuration, record or owner.
Provide exports of account lists, identifier generation logs and approval records that an examiner can review without asking for live access.
Document open gaps and planned fixes in a plan that your team can track, and confirm the independent assessor's evidence requests before handover.

How we support

Support is available as a retainer for upgrades, configuration changes and reviews of identifier evidence after handover.
Re-test identifier assignment and reuse controls after directory upgrades, new applications or changes to your authorization workflow.
Confirm with your assessor and your own environment which evidence format and retention period they expect before we agree on the final package.