IA-5(5): Change Authenticators Prior to Delivery

The ia-5(5): change authenticators prior to delivery requirement is a supply-chain and deployment control as much as it is an identity control. Your goal is simple: prevent “everyone knows the default” credentials from ever entering production, whether the component is hardware, firmware, a virtual appliance, a container image, SaaS administrative console access, or a managed service tool dropped into your environment.

Operationally, IA-5(5) forces clarity on two questions auditors always ask: (1) who is responsible for changing defaults (the developer/installer, you, or both), and (2) what evidence proves the change happened before the system was installed or accepted. Getting this wrong creates a quiet but material exposure: a third party ships you a device or image with default admin credentials, it gets deployed during a project rush, and the compromise path is trivial.

This page gives requirement-level implementation guidance you can put into procurement language, deployment runbooks, and acceptance checklists. It is written for a Compliance Officer, CCO, or GRC lead who needs to assign ownership, define “done,” and produce assessment-ready evidence without slowing engineering to a halt.

Regulatory text

Requirement (verbatim excerpt): “Require developers and installers of system components to provide unique authenticators or change default authenticators prior to delivery and installation.” ¹

What the operator must do: You must set and enforce a rule that system components cannot be delivered into your custody or installed into your environment with default authenticators. Practically, that means you (a) require the developer/installer to ship with unique authenticators per component or (b) require them to change defaults before delivery/installation and provide a secure way to transfer initial access to you. ¹

Plain-English interpretation

IA-5(5) is about eliminating “known starting secrets.” If an attacker can guess, find in a manual, scrape from the internet, or reuse a credential that is identical across devices, you have failed the control.

“Authenticators” here is broader than a password. In real deployments, scope commonly includes:

• Default admin passwords on devices, appliances, and management consoles
• Default SNMP community strings
• Embedded API keys or tokens in images or deployment templates
• SSH host keys and default private keys that get duplicated across instances
• Break-glass accounts created during installation

The control is satisfied when your process prevents these defaults from reaching production and you can prove it happened consistently.

Who it applies to

Entity scope

• Federal information systems and organizations implementing NIST SP 800-53 controls
• Contractors and service providers handling federal data or operating systems aligned to NIST SP 800-53 baselines ²

Operational scope (where this shows up)

• Procurement and third-party onboarding: purchase orders, statements of work, reseller agreements, managed service contracts
• Engineering and IT operations: golden images, MDM enrollment, network device provisioning, Kubernetes/VM templates, CI/CD artifact repositories
• Data center and endpoint deployment: staging rooms, “rack and stack,” desktop imaging, remote site rollouts
• Cloud and SaaS admin provisioning: initial tenant admin accounts, default roles, first API tokens

What you actually need to do (step-by-step)

1) Define “component” and “authenticator” for your environment

Create a short scoping statement for your standard:

• Component types: endpoints, servers, network gear, OT/IoT, virtual appliances, container images, SaaS tenants.
• Authenticators: passwords, keys, shared secrets, tokens, certificates used for authentication.

Make it executable by listing what is explicitly banned at delivery: factory defaults, shared credentials, and credentials stored in documentation or scripts in plaintext.

2) Set a clear responsibility model (RACI)

Decide which party must change defaults and when:

• Developer/installer-owned change: preferred for appliances and managed installs; they ship unique credentials or provide an attestation of change prior to delivery/installation.
• Customer-owned change during staging: acceptable when you have a controlled staging process that blocks production promotion until defaults are rotated.

Document this in a control procedure and in your acceptance criteria for deployments.

3) Put contractual hooks into third-party agreements

Add a clause to procurement templates and SOWs that requires:

• Unique authenticators per delivered unit or documented default change prior to delivery/installation. ¹
• Secure credential handoff method (for example, your approved secret manager, encrypted channel, or a one-time credential reset workflow).
• Prohibition on sending credentials in email, tickets, or manuals.
• Right to reject delivery if default credentials are present.

If you use Daydream to manage third-party due diligence workflows, map IA-5(5) to a standard contract addendum question set and require evidence at onboarding and renewal so this does not rely on memory.

4) Build an “Authenticator Change Gate” into receiving and staging

Operationalize a hard stop before any component is installed:

• Receiving checklist includes “default authenticator status verified.”
• Staging runbook includes a mandatory step: rotate defaults, create named admin accounts, disable vendor/shared accounts if not required.
• Promotion gate in CI/CD or image pipeline: block artifacts that contain embedded secrets or default keys.

This is where most programs succeed or fail. If the gate is optional, defaults will slip through during outages or urgent installs.

5) Standardize secure initial access and rotation

Create a repeatable pattern by platform:

• Hardware / appliances: unique per-device admin credential sealed to the device or delivered through a secure portal; forced reset on first login.
• VM images / containers: no baked-in credentials; bootstrap via instance identity, ephemeral tokens, or first-boot automation that pulls secrets from your secret manager.
• SaaS: enforce SSO before production use; disable local admin accounts where possible; rotate any initial API tokens created for setup.

6) Verify with technical checks, not only paperwork

Pair the paperwork with a real validation step:

• Attempt login with vendor default credentials in a controlled staging environment.
• Run configuration checks (scripts, scanner profiles, CIS-style checks where relevant) to detect known defaults.
• Confirm SSH host keys are unique per instance and not cloned from a template.

7) Record evidence at the moment of change

Evidence is easiest to capture during staging, not during the audit scramble. Build evidence collection into the ticket/work order:

• “Before” and “after” configuration snapshots (sanitized)
• Secret rotation logs from the secret manager
• Installer attestation plus your validation record

Required evidence and artifacts to retain

Keep artifacts that prove the control operates, not just that a policy exists:

Governance

• IA-5(5) control statement and procedure mapped to an owner and cadence ¹
• Secure credential handoff standard (allowed channels, secret manager requirement)

Third-party / procurement

• Contract language or SOW clause requiring unique authenticators or default changes prior to delivery/installation
• Third-party implementation attestation ¹
• Exception approvals (with compensating controls and remediation date)

Operational / technical

• Staging/installation checklists with sign-off
• Build pipeline evidence (for images/templates) showing secret scanning and bootstrap controls
• Change records/tickets showing default credential rotation completed
• Screenshots or command output demonstrating defaults removed (sanitize secrets)

Common exam/audit questions and hangups

Auditor question	What they are testing	How to answer with evidence
“How do you know components don’t ship with default passwords?”	Supply-chain control design	Show contract clauses, receiving checklist, and rejection criteria.
“Show me proof for a sample of recent installs.”	Operating effectiveness	Provide install tickets with rotation step completed and validation output.
“Who is accountable: you or the installer?”	Role clarity	Provide RACI and SOW language aligned to your procedure.
“How do you handle exceptions?”	Governance maturity	Provide exception register with approvals and follow-up closure proof.

Frequent implementation mistakes and how to avoid them

1. Relying on policy-only compliance. A written requirement without a staging gate fails under pressure. Add a deployment gate and ticket evidence requirements.

2. Treating “unique” as “same password, different device.” Unique means not shared and not predictable. Prefer generated secrets and forced rotation on first use.

3. Letting installers keep a permanent admin account. If a third party needs access, make it time-bound, named, and logged. Remove it when the work ends.

4. Shipping credentials through email or PDF manuals. This creates uncontrolled copies. Use your secret manager or an approved secure transfer method with access logs.

5. Forgetting non-password authenticators. API tokens, SNMP strings, SSH keys, and baked-in secrets in images are common failure points. Expand your checks beyond “password changed.”

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat “enforcement” here as assessment and incident risk rather than specific penalty risk. The practical risk is straightforward: default or shared authenticators create a low-effort compromise path, especially for internet-exposed management interfaces, remote access tooling, and devices deployed at scale. IA-5(5) also intersects with third-party risk: if your supplier repeatedly ships insecure defaults, it is a systemic control weakness you need to address through procurement and acceptance testing. ²

A practical execution plan (30/60/90)

First 30 days (Immediate)

• Assign a control owner across IT/Engineering and Procurement.
• Publish an IA-5(5) standard: define “authenticator,” define banned default conditions, define allowed handoff methods. ¹
• Update one procurement template (SOW or MSA addendum) with the IA-5(5) clause.
• Add an “Authenticator Change Gate” checkbox to installation tickets and receiving checklists.

Next 60 days (Near-term)

• Implement technical validation for at least your highest-risk component classes (internet-exposed devices, remote management tools, standard images).
• Stand up an exception process with documented compensating controls and tracking.
• Train installers and internal deployers on the staging runbook and evidence capture.

By 90 days (Operationalized)

• Expand coverage across all component types in your asset inventory.
• Make the gate non-optional: no production promotion without evidence attached to the ticket.
• Add recurring third-party checks: require attestations and evidence at onboarding and material changes, and review during renewals.

If you need to move fast, Daydream fits naturally as the system of record to map IA-5(5) to a control owner, documented procedure, and recurring evidence artifacts so audits do not turn into email archaeology. ¹

Frequently Asked Questions

Does IA-5(5) mean the third party must always set the password for us?

No. IA-5(5) allows either unique authenticators to be provided or default authenticators to be changed prior to delivery and installation. Your process must still prevent default credentials from reaching production. ¹

What counts as “prior to delivery and installation” in cloud deployments?

Treat “delivery” as the point you accept an image, template, tenant, or configuration into your repositories or accounts. Treat “installation” as the first time it is deployed into an environment that can reach production data or networks.

Can we accept a device with defaults if we rotate credentials during staging?

The requirement language targets change prior to delivery and installation, so accepting defaults creates compliance friction. If you choose staging rotation, document the gate that prevents any installation into production until defaults are changed and verified, and track any exceptions explicitly. ¹

How do we handle break-glass accounts created by installers?

Require named accounts tied to individuals for installation activities, then disable or rotate credentials at handoff. If you must keep break-glass access, store it in your secret manager and test access under controlled procedures.

What evidence is strongest for auditors?

A complete chain: contract clause, install ticket with a required rotation step, technical validation output, and secret manager audit logs showing creation/rotation. Policy alone rarely satisfies operating effectiveness.

Do “unique authenticators” include SSH host keys and API tokens?

Yes in practice, because they are authenticators used for authentication. Include them in your definition and add checks for cloned keys or embedded tokens in images.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5