IA-5 Authenticator management: requirements and evidence

What IA-5 authenticator management asks for and why it decides identity assurance

If an audit, a baseline selection or an engineering backlog includes IA-5, the organization has to control every password, token, certificate and similar authenticator from issuance to retirement. IA-5 Authenticator management in NIST SP 800-53 Rev. 5 asks for nine duties: verify identity before an authenticator is distributed, set initial content, require sufficient strength, handle lost, compromised and revoked authenticators, change default authenticators before first use, refresh them on a defined schedule or event, protect authenticator content, and change group account authenticators when membership changes. The control is about the whole life cycle, so an assessor will look for a process that covers each duty, not just a strong password policy. The risk is concentrated in authenticators that nobody tracks. Weak, default or shared credentials are a common route into systems, and they tend to multiply across business applications, service accounts, API keys, network devices and vendor access. Each of these has its own issuance path and its own idea of expiry, so the duties above are easy to satisfy for the directory and easy to miss everywhere else. Before planning work, the reader should confirm which authenticator types exist in the environment and who issues each one, because the SP 800-53A examine procedures start from a list of system authenticator types. IA-5 is selected at the low, moderate and high baselines in SP 800-53B Release 5.2.0 but not at the privacy baseline. The baselines also select three enhancements: IA-5(1) for password-based authentication at all three impact levels, and IA-5(2) for public key-based authentication and IA-5(6) for protection of authenticators at the moderate and high levels. Organizations should confirm the exact selections against the OSCAL baseline profiles before scoping, since enhancement selections are the detail most often misread. Withdrawn enhancements IA-5(3), IA-5(4) and IA-5(11) are not part of the current catalog.

Which authenticators, systems and teams fall under IA-5 scope

IA-5 reaches further than password policy. The scope you draw decides which authenticators, systems and third parties need lifecycle controls, evidence and assessment effort. Settle these boundaries before inventory work starts, because each one changes how many items the assessor will sample.

Human passwords and enrolled second factors

Start with the authenticators people hold: passwords, one-time codes, security keys and passkeys. IA-5(1) governs password-based authentication and is selected in the low, moderate and high baselines, so every organizational user population in the system boundary is in scope. Check whether second factors enrolled through an identity provider, such as TOTP apps, WebAuthn or static recovery codes, are inventoried with the same owners, issuance records and revocation steps as passwords. Ask your identity team which second-factor types are actually enrolled, not only which ones are allowed.

Hardware, software and PKI certificates

Tokens and certificates carry their own life cycle: issuance after identity verification, renewal, revocation and protection of private keys. IA-5(2) covers public key-based authentication and is selected at the moderate and high baselines, which means PKI certificate authorities, enrollment workflows and hardware token stock fall within the assessed scope. Confirm which certificate authority issues each certificate class, whether revocation is logged, and who can request a replacement. Missing revocation records are a common gap during sampling.

Service accounts, API keys and machine secrets

Non-human authenticators are often the largest population and the least documented. API keys, database credentials, CI/CD tokens and service certificates each need an owner, a rotation trigger and a revocation path. Plan the discovery step carefully, because secrets committed to code repositories or stored in configuration files may not appear in any inventory. Tools that scan repositories and vaults can help build the list, but their output still needs human review and an owner assigned to each finding.

Biometrics and devices enrolled for authentication

Biometric templates and device-bound credentials are authenticators too. Where a biometric unlocks a device or confirms identity for a system in the boundary, record where the template is stored, whether it leaves the device, and how enrollment is reset when a user leaves or a device is lost. Biometric and device enrollment often sits with an endpoint or mobile management team rather than the identity team, so assign the scope to both. Confirm with your assessor whether the biometric mechanism is part of the system boundary or only a supporting service.

Group and shared accounts

Shared logins, break-glass accounts and role mailboxes are authenticators used by several people, so IA-5 requires a change of the authenticator when membership changes. Build a register of every group account, its members and the date its credential last changed. Each departure or role change that touches a shared account becomes an assessable event, so the process should trigger automatically from HR or access reviews. Ask whether shared accounts can be eliminated in favor of individually assigned accounts with delegated privilege.

Third parties that issue or hold authenticators

Managed identity providers, outsourced help desks, managed PKI services and software-as-a-service vendors may issue, reset or store authenticators on your behalf. Your organization still owns the control, so the contract, the vendor's identity verification steps and its incident notification terms all count as evidence. Request the vendor's own assessment reports and the configuration you rely on, and confirm in writing which party performs each authenticator task. Gaps usually appear at the handoff between your team and the provider.

How an assessor tests IA-5 against SP 800-53A

This table shows how an assessor applies the examine, interview and test methods from SP 800-53A to IA-5, with the evidence each method requests and the findings that most often appear. Read each row as one assessment thread that the organization should be able to walk through before the assessor arrives. SP 800-53A assigns IA-5 ten determination statements, so the evidence has to cover policy, records, people and technical mechanisms together.

Assessment method	How the assessor tests it	Evidence requested	Common findings
Examine: authenticator types	Reviews the documented list of authenticator types in use, such as passwords, tokens, certificates and biometrics, and checks it against the system's actual authentication paths.	Authenticator type inventory, system authentication design documents, and the mapping of each type to the systems that use it.	Authenticator types exist in production that never appear in the documented list, such as service certificates or legacy API keys.
Examine: change control records	Samples change tickets and approvals for authenticator management actions, including issuance, resets, revocations and group membership changes.	Change control records tied to authenticator actions, with approver, date and the account or group affected.	Authenticator changes are made directly in administrative consoles with no ticket, so no record exists for the assessor to sample.
Examine: system audit records	Traces sampled authenticator events through system logs to confirm that issuance, change, lock and revocation were recorded.	Audit records for authenticator lifecycle events, retained for the period the assessor selects.	Logs capture logins but not credential resets, enrollments or revocations, leaving the lifecycle unprovable.
Interview: authenticator management personnel	Asks staff who issue, reset and revoke authenticators to walk through the procedure and identity checks they apply at distribution.	Named role holders, a written procedure they follow, and examples of identity verification performed for recent issuances.	Staff describe a procedure that differs from the written one, or identity checks depend on who the requester knows.
Interview: system and network administrators	Asks administrators how default authenticators are changed before first use, how shared and service credentials are rotated, and how group account membership changes flow into authenticators.	Administrator runbooks for first-use changes, rotation schedules, and the process that updates group account credentials on membership change.	Vendor default passwords remain on appliances or databases because the first-use change step was never added to build checklists.
Test: authenticator management mechanisms	Exercises the mechanisms that enforce strength, expiry, lockout, revocation and protection of stored authenticator content, and checks whether they behave as documented.	Configuration exports or screenshots of password and certificate policy settings, and test results showing revocation and expiry take effect.	Password policy is documented as enforced but the directory accepts weaker values, or revoked tokens still authenticate.
Test: group account changes	Changes a sample group membership in a test environment and checks that the group's shared authenticator is rotated or access is removed as the procedure states.	Test records from a controlled membership change, showing the before and after state of the group credential.	Membership changes are applied to access lists but the shared password on the group account is never rotated.
Test: secret storage and protection	Checks where authenticator content such as password hashes, keys and tokens is stored, who can read it, and whether it is encrypted or short-lived.	Storage design, access control lists for secret stores, and evidence of encryption or dynamic credential issuance where used.	Credentials sit in plaintext configuration files or repositories, and a secret scan has never been run against them.

How to implement IA-5 in a sequence an assessor can follow

This sequence takes an organization from an unmanaged set of passwords, keys and tokens to a documented authenticator program in which each step leaves an artifact that an assessor can trace against the IA-5 determination statements. Work through the steps in order, because later steps depend on the inventory and rules produced earlier.

Inventory every authenticator type and holder
Start by listing each authenticator the environment issues or accepts: passwords, one-time password tokens, hardware keys, PKI certificates, API keys, service account secrets and any biometric enrollment. For each type, record which systems use it, which population holds it (employees, contractors, service accounts, devices, outside users) and who owns its issuance. The output is an authenticator inventory that the assessor will compare against the list of system authenticator types they examine. Done is when every system in the authentication boundary appears in the inventory with an owner for each authenticator type.
Define issuance identity checks and initial content rules
For each authenticator type, document how the organization verifies the identity of the holder before the authenticator is handed over, such as in-person verification, a verified channel to a known contact or a supervisor's confirmation. Then define the rules for initial content: who generates it, how it is delivered, how long it stays valid before first use and whether it must be unique per person. The output is an issuance procedure with its checks written out, plus sample issuance records showing that the checks ran. Confirm the requirements for your own environment with your auditor, since the assessment will test what your procedure says and what your records show.
Set strength rules and default change requirements
Translate the strength requirements into technical settings for each authenticator type, covering password length and complexity, token types, certificate key parameters and lifetime. Include a rule that vendor and factory defaults are changed before first use, and configure the platforms so that a default credential cannot remain active. The output is a strength standard tied to configuration baselines, plus a configuration export or scan result showing that the settings are in force. Ask your platform vendors which parameters they expose, because the evidence is only as strong as the settings you can show.
Define refresh triggers and revocation procedures
Set the schedule or event conditions that require an authenticator to be refreshed, and write the procedures for lost, compromised and revoked authenticators. Each procedure should name the trigger, the person or system that acts, how the authenticator is disabled and how the event is recorded. Staff departures and role changes belong here as revocation triggers. The output is a refresh and revocation standard with the specific schedule or event list the organization chose, along with sample tickets or logs showing a revocation carried out end to end.
Implement protection of authenticator content
Decide where authenticator content is stored and how it is protected at rest and in transit. Secrets that machines need should live in a central, access-controlled store rather than in source code, configuration files or chat logs. Where dynamic, short-lived credentials are feasible, prefer them because they expire automatically. Self-hosted options such as OpenBao (MPL-2.0) store secrets encrypted in one place and attach leases that revoke credentials on expiry. Secret scanning in CI, such as GitLab's pipeline secret detection (MIT), can flag secrets committed to repositories. The output is the storage design, access policy, and scan reports or revocation records that show protection works in practice.
Define group account change handling
For any shared or group account, define how the authenticator changes when membership changes. Document which members hold access, the trigger for a change (a departure, a role change or a removal from the group) and the steps to rotate the shared secret or re-issue the credential. Prefer individual accounts where the system allows them. The output is a group account register listing each shared account, its members and rotation history, along with rotation records that show the authenticator changed after each membership change.
Assemble the evidence set for the assessor
Gather the artifacts from the earlier steps into one evidence package organized by the IA-5 determination statements and the assessment methods in SP 800-53A: examine (policy, inventory, change control records, audit records), interview (personnel with authenticator responsibilities and administrators) and test (the mechanisms that enforce the rules). Map each artifact to the statement it supports, and note gaps before the assessor finds them. Confirm with the independent assessor which samples and time periods they will request. The output is an evidence index that lets the assessor trace every statement to a document, record or test result.

How the password and PKI enhancements change the work

The baseline decides which IA-5 enhancements are mandatory, and that choice changes the scope of the work more than any single control text. SP 800-53B Release 5.2.0 selects IA-5(1) for password-based authentication at the low, moderate and high baselines, so every system categorized at any impact level needs password evidence. IA-5(2), which covers public key-based authentication, and IA-5(6), which covers protection of authenticators, are selected only at moderate and high. A system that moves from low to moderate therefore adds certificate handling and authenticator protection to its evidence set, not just more password records. IA-5 has 18 numbered enhancements in Release 5.2.0, but IA-5(3), IA-5(4) and IA-5(11) are withdrawn, leaving 15 current enhancements. Check the baseline your system actually uses in the OSCAL profile before you size the evidence, and confirm that your assessment team is working from the same release.

The enhancements set requirements, but the organization sets the values. For password-based authentication, the organization decides the composition, length, reuse and lockout rules that its policy and system configuration will enforce. For public key-based authentication, it decides how certificates are issued, validated, mapped to accounts and revoked, along with the trust anchors it accepts. Neither choice is made by the control text, so an assessor will ask for the documented parameters and then test that the running system matches them. Keep the password policy, identity provider settings, certificate profile and revocation procedure in version control, and retain a dated record of each change. An assessor will compare a configuration export against the approved parameters, so a policy that says one thing while the directory enforces another will fail.

For IA-5(6), protection of authenticators, the practical question is where secrets live and who can read them. Private keys, token seeds, service credentials and recovery codes all need controlled storage, access logging and a clear owner. Self-hosted tools can supply part of this evidence. OpenBao stores secrets encrypted in one place and can issue short-lived dynamic credentials with leases that revoke automatically, and GitLab Community Edition's pipeline secret detection writes a gl-secret-detection-report.json artifact that can show whether credentials were committed to source. FreeIPA's OTP support, including HOTP and TOTP tokens, supplies enrollment and token records for second-factor authenticators. Confirm with each vendor which capabilities your version provides, and expect the assessor to test the mechanisms themselves rather than accept the tool's description.

Which evidence passes an IA-5 assessment and how to keep it current

An assessor testing IA-5 looks for records that show how each authenticator type was issued, configured, changed and protected over time. The cards below cover six artifacts that usually answer those questions, and each one needs a routine refresh between formal assessments so it reflects the system as it runs today.

Authenticator type inventory

This is the list of every authenticator type the system uses, such as passwords, hardware tokens, PKI certificates, API keys and service credentials, with the owning group and the systems each one covers. Assessors start here because it defines the scope of the other records. Regenerate it on a fixed schedule and after any new identity provider, token vendor or service onboarding, then compare it against the directory and secrets stores to catch authenticators that were never inventoried.

Issuance and identity verification records

These records show who received each authenticator, how the recipient's identity was checked before issuance, and who set the initial content. Keep the verification step tied to the request ticket so the link is visible. Between audits, sample a set of recent issuances each quarter and confirm that every one has a matching verification entry, and investigate any gap as an exception.

Password and strength configuration exports

Exports of the password policy, complexity and length settings, and any enabled checks for compromised or reused passwords, show that the required strength is enforced in the system rather than only written in policy. Export the active settings from each directory and identity provider, store them with a timestamp, and diff them against the approved baseline. Any drift should open a change record.

Default change and first-use records

Vendor and factory defaults on appliances, databases, service accounts and new tokens must be changed before first use. Keep a record for each system showing the default was replaced, when, and by whom. Between audits, scan for default credentials on newly deployed hosts and retain the scan output alongside the change record so the check is repeatable.

Refresh, revocation and lost-authenticator logs

These logs show that authenticators were refreshed on the defined schedule or triggering event, and that lost, compromised or departed-user authenticators were revoked. Pull the events from the identity provider and secrets manager, match each revocation to a ticket, and confirm that the refresh interval in the log matches the documented one. Gaps between expected and recorded refreshes are the usual finding.

Group membership and secret protection records

When people join or leave a shared account, its authenticators must change, so keep membership change records linked to the reset that followed. Pair them with configuration evidence showing where authenticator content is stored, encrypted and access-controlled, such as secrets manager policies and secret scanning reports. Review a sample of group changes each quarter and confirm that each one has a matching reset entry.

What meeting IA-5 costs in money and effort

This table breaks the cost of meeting IA-5 into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs, so use the table to structure a written quote rather than to read off a price. The main takeaway is that the largest variable costs come from the number of authenticator types and systems, not from the control text itself.

Cost component	One-time or recurring, and who is paid	What drives it up or down	How to keep it down
Identity and secret management tooling	Recurring if licensed, one-time for setup. Paid to a software vendor or, for self-hosted open source, to the internal team and any implementation partner.	Number of authenticator types, number of systems, and whether an existing identity provider already issues credentials.	Use self-hosted open-source options such as OpenBao, authentik or FreeIPA where they fit the environment, and confirm license terms and support needs before choosing.
Engineering time to configure strength, defaults and protection	One-time for initial configuration. Paid as internal engineering time or as a fixed-scope implementation engagement.	Number of password policies, PKI certificate profiles, and systems that accept local credentials, plus whether defaults are already changed.	Scope the password and PKI enhancements you actually select, and reuse one policy across systems wherever the platform allows it.
Authenticator lifecycle records and evidence upkeep	Recurring. Paid as internal staff time to keep change records, revocation logs and refresh evidence current.	Maturity of current records, volume of joiners, movers and leavers, and how many group accounts change membership.	Route authenticator issuance, revocation and group membership changes through one ticketed workflow so evidence is produced as a by-product.
External testing or review of the configuration	Recurring or periodic. Paid to a security testing firm or implementation partner for a configuration review or test.	Number of authenticator types under test, exposure of systems, and whether testing is already part of a wider program.	Ask for a review limited to the authenticator mechanisms in scope, and combine it with testing already planned for the system.
Auditor or assessor sampling time	Recurring per assessment cycle. Paid to the independent assessor, which does not issue reports through DeployOpen.	Number of authenticator types, sample sizes the assessor selects, and how quickly evidence can be retrieved.	Prepare a sample-ready evidence index for IA-5 before the assessment so the assessor can test without long retrieval cycles.
Quote itemization to request	Written scope and quote. Each line should name the work, who performs it and whether it is one-time or recurring.	Clarity of scope, which systems and authenticator types are included, and whether licenses are separate from services.	Ask for line items for tooling, configuration, evidence setup, testing and recurring upkeep, and confirm which assumptions the quote depends on.

Which open-source tools can produce IA-5 evidence

Authenticator management leaves evidence in several places: the secrets store, the code pipeline, the login flow and the directory. The four tools below each cover a different part of that life cycle, so a team can match each one to the evidence it needs to show an assessor.

OpenBao secrets management

OpenBao is an MPL-2.0 licensed secrets manager that stores secrets encrypted in one place. It generates dynamic, short-lived credentials for systems such as databases, attaches a lease to each credential so it revokes on expiry, and can revoke a single secret or a whole tree of credentials. For IA-5, this supports refresh on a defined schedule and revocation of compromised or retired authenticators. Confirm lease, revocation and audit behavior against your deployed version and auth method configuration.

GitLab pipeline secret detection

GitLab Community Edition (MIT) includes pipeline secret detection, which scans files committed and pushed to the repository inside a CI/CD job. Detected secrets are written to a gl-secret-detection-report.json job artifact, and this runs in every tier. That artifact helps show that hard-coded passwords, tokens and keys are caught before release, which speaks to protecting authenticator content. Confirm the scanner rules, coverage of your file types and how findings are triaged in your own pipeline.

authentik authenticator validation

authentik is an MIT licensed identity provider. Its authenticator validation stage checks enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. Login logs from this stage can show which authenticator types are in use and which were rejected. Check which factor types you permit, how static recovery codes are issued and stored, and whether SMS and email codes meet your strength decision.

FreeIPA OTP tokens

FreeIPA (GPL-3.0-or-later) supports two-factor authentication with HOTP and TOTP tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys. It can also proxy OTP checks to an existing RADIUS server during migration, which helps when authenticators move between systems. For IA-5, token enrollment and assignment records can evidence identity checks at issuance and lost or revoked token handling. Confirm the token types, enrollment workflow and RADIUS proxy behavior in your release before relying on them.

Who owns IA-5, who prepares evidence and who issues the opinion

The organization owns IA-5. Its leadership accepts the risk of how users, services and devices receive, use, change and lose authenticators, and its own staff write the policy, set the authenticator rules and answer for them during an assessment. The control is not something a vendor or partner can hold on the organization's behalf, even when outside help builds the tooling.

Policy and rules: Define which authenticator types are allowed, the strength requirements, refresh triggers and the process for lost, compromised and revoked authenticators.
Identity checks at issuance: Decide who verifies identity before an authenticator is handed out and keep that verification recorded.
Group account changes: Assign an owner who updates shared credentials whenever membership changes.
Operation and records: Run the authenticator process day to day and keep change control records and audit records that show it happened.
Decisions on exceptions: Approve any deviation from the baseline and track it until closed.

Before engaging anyone, confirm internally who signs the IA-5 procedure and who will be interviewed about it, because assessors test those people directly.

Where IA-5 programs usually fall short and how to close each gap

Most IA-5 findings come from a small set of recurring problems: an incomplete authenticator inventory, defaults left in place, and secrets and group credentials that no one tracks. Each card below names one gap, what an assessor will look for, and a remedy that produces evidence an assessor can test.

Authenticator types missing from the inventory

IA-5 assessments start with a list of system authenticator types, so an inventory that covers only passwords misses certificates, API keys, service tokens, hardware tokens and SSH keys. Build the inventory from systems, not from policy. Pull identity provider configurations, directory schemas, certificate stores, secret managers and appliance admin consoles, then record for each authenticator type its issuer, lifetime, owner and the system it protects. Re-run the inventory whenever a new system is onboarded.

Default credentials left on appliances

Vendor appliances, network devices and service accounts often ship with default passwords that survive installation. IA-5 requires changing defaults before first use, so an assessor will check the setup records for each device class. Test every device class during build acceptance. Confirm that default accounts are disabled or rotated, and keep the change record with the device serial or hostname. Include service accounts created by installers, which are easy to overlook because no person logs in with them.

Shared accounts keep old authenticators

Group and shared accounts often retain the password or key that a former member knew after that person leaves or changes role. IA-5 calls for changing group account authenticators when membership changes, so this gap shows up in access reviews and audit records. Tie rotation to the HR or group membership event. Assign each shared account a named owner, log every membership change, and rotate the authenticator in the same workflow. Keep the rotation record with the membership change so both can be sampled together.

Secrets committed to source repositories

Passwords, tokens and private keys committed to code repositories are authenticators outside the managed store, and they persist in history even after deletion. Scan on commit and move secrets into a managed store. Run pipeline secret detection on every push and keep the scan artifacts as evidence. Replace static values with a secret manager that issues short-lived credentials and revokes them automatically, so a leaked value expires on its own schedule.

No defined trigger for refresh

Many programs state that authenticators are refreshed periodically but never define the period for each type, or the events that force an earlier refresh such as a suspected compromise or a privileged role change. IA-5 requires refresh on a defined schedule or event, so the parameter values must be written down. Set a refresh rule per authenticator type. Document the interval, the event triggers and the owner who confirms completion, then test a sample of accounts against those values.

Evidence not tied to a control statement

Logs, screenshots and tickets exist, but they are stored without a reference to the IA-5 requirement they support, so an assessor cannot trace them. Map each evidence source to the IA-5 determination statements. Build a short matrix that lists the artifact, the system it comes from, the collection date and the statement it answers. The 10 determination statements in SP 800-53A give a practical checklist for that matrix.

Questions buyers ask about IA-5 cost, effort and outside help

How much effort does IA-5 authenticator management take?

The effort depends less on writing the procedures than on how many authenticator types and systems the organization runs. Passwords, MFA tokens, PKI certificates, API keys, service credentials and group accounts each need an issuance process, a strength standard, a rotation or revocation path and evidence that the path works. Effort rises sharply when authenticators are spread across directories, cloud consoles, network devices and legacy applications that each handle defaults and resets differently. Ask any prospective partner to inventory these authenticator types before quoting, because that inventory sets most of the work.

Can we do IA-5 in-house without an outside partner?

Yes, many organizations do, provided they own the control and have people who can configure identity systems and produce evidence. The work splits into policy and process ownership, technical configuration of identity and secrets tooling, and evidence collection for assessors. Teams with an existing identity provider, a secrets manager and a clear owner for authenticator policy usually find the gap is smaller than expected. Teams that lack these skills, or that must meet a deadline set by a contract or regulator, often bring in a partner for the technical build while keeping ownership internally.

What does the work need from our internal team?

Expect a named control owner, an identity engineer, system administrators for each authenticator-bearing platform, and a reviewer from security or compliance who can read assessment procedures. Owners must approve identity proofing rules for issuance, the strength standard, refresh triggers and the group account change process. Administrators need time to change defaults, migrate credentials and test revocation, which often interrupts normal operations. Ask a partner to name which of these roles it will fill and which your staff must fill, so responsibilities are written into the agreed scope from the start.

How long does an IA-5 implementation take?

Duration depends on scope, meaning the number of authenticator types, platforms, user populations and existing automation. No supplied figure exists for a typical timeline, so do not rely on a general number from any source, including this page. Ask for a fixed-scope timeline in writing that lists the deliverables, the systems covered, the dependencies on your team and the review points. A credible plan separates a discovery phase from configuration, testing and evidence collection, and it names what happens if an authenticator type turns out to be out of scope.

Can a consultant or implementation partner certify IA-5 compliance?

No. The organization owns its controls, an implementation partner prepares systems and evidence, and only an independent assessor or certification body issues findings, reports or certificates. For NIST SP 800-53 work, the assessment is performed under the authorization process that applies to your system, such as an agency or contract requirement, and the assessor tests IA-5 against the assessment procedures in SP 800-53A. A partner can make that assessment faster and less disruptive by preparing evidence, but it cannot replace the assessor's judgment. Confirm the assessor's requirements before the engagement starts.

Do open-source tools satisfy IA-5 on their own?

No single tool satisfies IA-5. Open-source platforms can produce strong evidence for several parts of the control, such as centralized secrets storage with leases that expire and revoke credentials automatically, pipeline scans that detect committed secrets, and multi-factor enrollment and validation for users. Other parts, including identity checks at issuance, group account membership rules, strength policy and the review cadence, remain organizational processes. Tools also need to be configured, hardened and monitored, and their logs must reach the assessment file. Confirm each capability in your own environment before relying on it in an assessment.

How DeployOpen scopes, implements and prepares IA-5 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms that handle authenticator management for IA-5 inside the client's own cloud accounts, data centers or air-gapped networks. We prepare the systems, settings and records that an assessor will examine, while the organization keeps ownership of its controls and an independent assessor decides the outcome.

How we scope

We agree in writing which authenticator types, such as passwords, tokens, certificates and biometrics, fall inside the IA-5 scope.
We map the written scope to the IA-5 determination statements and the platforms that enforce each one.
We confirm with your team who owns authenticator policy, group account changes and the refresh schedule before work starts.

How we build

We configure self-hosted platforms for password-based and second-factor authenticators, including enrollment and recovery checks.
We set up secrets storage with short-lived credentials and revocation so authenticator content is protected and expires on schedule.
We enable secret detection in the delivery pipeline and test that revoked and default authenticators are rejected.

How we hand over

We deliver configuration records, test results and audit log samples mapped to each IA-5 assessment objective in scope.
We document the authenticator procedures, owners and review cycle so your team can run them after handover.
We state which evidence only your organization or the independent assessor can produce, such as interview records and policy approvals.

How we support

Ongoing support, upgrades and continuous testing of authenticator controls are available as a retainer after handover.
A retainer can cover platform upgrades, periodic checks of default credentials and refresh of evidence before an assessment.
Any change to scope after signature is handled through a written change to the agreed scope and its timelines.