IA-5(7): No Embedded Unencrypted Static Authenticators

IA-5(7) requires you to prevent passwords, API keys, shared secrets, private keys, and other static authenticators from being embedded in code or stored in any static location in unencrypted form. Operationalize it by scanning for secrets, removing hardcoded credentials, moving secrets into an approved secrets manager, and retaining evidence that the prevention and detection controls run continuously. ¹

Key takeaways:

• Block hardcoded secrets at the source with SDLC guardrails, not just cleanup projects. ¹
• Treat “static storage” broadly: source repos, containers, images, configs, CI logs, AMIs, backups, and tickets can all qualify. ¹
• Keep assessor-ready evidence: scan results, remediation tickets, exceptions, and secrets platform configuration. ¹

The ia-5(7): no embedded unencrypted static authenticators requirement is a simple sentence that creates real engineering work: “don’t hide credentials in places that don’t change and aren’t encrypted.” If an attacker gets your repo, a container image, a shared drive, or a build log, embedded authenticators turn that exposure into immediate system access. IA-5(7) pushes you toward two outcomes: (1) static authenticators must not be present in application artifacts or static storage in unencrypted form; and (2) you must be able to show how you prevent reintroduction and how you detect drift. ¹

For compliance owners, the trap is treating this as a one-time “secret cleanup.” Auditors will ask how you know it stays fixed across new releases, new third parties, and new pipelines. The practical operating model is: enforce secure secret handling patterns (secrets manager + runtime injection), run automated secret scanning across the SDLC, and manage exceptions with explicit risk acceptance and compensating controls. ¹

Daydream can help by mapping IA-5(7) to a named owner, an implementation procedure, and recurring evidence artifacts so assessments do not depend on tribal knowledge. ¹

Regulatory text

Requirement (excerpt): “Ensure that unencrypted static authenticators are not embedded in applications or other forms of static storage.” ¹

Operator interpretation:
You must ensure that secrets that can authenticate (passwords, tokens, API keys, shared secrets, private keys, database credentials, device credentials, service account passwords) are not:

• Embedded in applications (source code, compiled binaries, packaged artifacts, container images, mobile apps, IaC templates checked in for deployment), or
• Placed in static storage (configuration files, scripts, build logs, tickets, wikis, shared drives, AMIs/snapshots, backups, CI artifacts) when they are unencrypted. ¹

This is a prohibition plus an expectation of sustained control: you need prevention, detection, and remediation workflows that are repeatable and evidenced. ¹

Plain-English interpretation (what counts and what doesn’t)

What is a “static authenticator” in practice?

A static authenticator is any secret that does not rotate automatically per use and can be replayed to authenticate. Common examples:

• API keys and bearer tokens used for service-to-service auth
• Database usernames/passwords embedded in app configs
• SSH private keys stored in repos or on shared drives
• Cloud access keys stored in scripts
• “Default” device credentials left in firmware/configs
  If it grants access, treat it as an authenticator for IA-5(7) scope. ¹

What does “embedded” mean?

“Embedded” includes hardcoding in:

• Source code (including examples, tests, and “temporary” debug code)
• Configuration committed to version control
• Build-time variables written into artifacts or images
• Client-side apps (mobile, SPA) where secrets are exposed by design
  If a developer can grep it, or a user can extract it from an artifact, assume it is embedded. ¹

What does “unencrypted” mean?

For audit purposes, “unencrypted” generally means the secret is stored in cleartext or trivially recoverable form (for example, base64-encoding is not encryption). The safe pattern is to store secrets only in an approved secrets system and inject them at runtime with access controls and audit logging. ¹

Who it applies to

Entities

IA-5(7) is relevant to:

• Federal information systems
• Contractor systems handling federal data (for example, systems supporting federal contracts) ¹

Operational context (where you will find issues)

You should assume findings can exist anywhere software or infrastructure is created, packaged, or stored:

• Engineering repos (app code, IaC, pipelines)
• CI/CD platforms and build logs
• Artifact registries (container registries, package registries)
• Cloud images/snapshots/backups
• Operations runbooks, tickets, and shared documentation
• Third-party delivered code, appliances, or “drop-in” scripts
  Third parties matter here because delivered artifacts can arrive with embedded secrets or with patterns that encourage embedding secrets (for example, sample configs with passwords). ¹

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

1) Name ownership and define the rule

• Assign a control owner (usually AppSec, IAM, or Platform Security) with authority to set SDLC requirements.
• Publish a short standard: “No static authenticators in code or static storage unless encrypted and approved; secrets must live in managed secret storage.” ¹

Daydream tip: Track IA-5(7) as a control with an owner, procedure, and evidence list so you can answer “who runs this, how, and how often” consistently. ¹

2) Define “static storage” in your environment (scope map)

Create a one-page scope map covering, at minimum:

• Code repos (all orgs, including “legacy”)
• CI/CD systems and build artifact retention locations
• Container registries and VM image pipelines
• Configuration stores (GitOps repos, config management)
• Backup and snapshot locations
• Collaboration platforms used for sharing configs
  This becomes the baseline for scanning and for audit scoping. ¹

3) Implement approved secret handling patterns

Put in place standard patterns engineers can follow:

• Secrets manager as source of truth (cloud-native or enterprise)
• Runtime injection (environment variables, workload identity, sidecar, CSI driver)
• Strong access controls and audit logging for secret reads
• Rotation workflows for impacted secret types
  The compliance goal: developers do not need to “solve secrets” ad hoc by hardcoding them. ¹

4) Add automated detection across the SDLC

Minimum detection points that auditors expect to see:

• Pre-commit / pre-push guidance (developer tooling) to catch obvious secrets early
• Repo scanning across default and long-lived branches
• CI pipeline scanning to prevent secrets from entering build artifacts
• Container/image scanning to detect secrets copied into images
  Configure alerting and a triage queue with SLAs you can defend internally (define them as policy, not as a “fact”). ¹

5) Build a remediation workflow that proves closure

Operationalize a consistent workflow:

1. Create a ticket with location, secret type, and exposure path.
2. Remove the secret from the artifact and purge it from history where feasible (for repos, consider history rewrite and re-issue clones guidance).
3. Rotate/revoke the secret.
4. Verify no downstream copies exist (images, backups, forks, CI artifacts).
5. Record closure evidence (scan result showing clean state + rotation confirmation). ¹

6) Manage exceptions explicitly (and keep them rare)

Some edge cases exist (legacy systems, vendor appliances, offline systems). If you approve an exception:

• Require encryption mechanism details and key management approach
• Require compensating controls (restricted access, monitoring, rotation)
• Set an expiration date and a migration plan
• Document risk acceptance with the approving authority
  Assessors will look for whether exceptions are controlled or whether exceptions have become the norm. ¹

7) Extend to third parties and delivery pipelines

Add contract and intake controls:

• Require third parties to attest they do not ship embedded unencrypted authenticators in code/artifacts you ingest.
• Scan third-party code drops and container images before promotion.
• Require secure configuration guidance that avoids “put the password in this file” defaults. ¹

Required evidence and artifacts to retain

Keep evidence that shows both design and operation:

Evidence artifact	What it should show	Owner
IA-5(7) control narrative + procedure	Scope, prohibited patterns, approved secret storage, exception process	GRC + Control owner
Secret scanning tool configuration	Scan targets, rulesets, pipeline gates, alerting	AppSec/DevOps
Scan outputs (point-in-time and recurring)	Findings list, severity, timestamps, repos/images scanned	AppSec
Remediation tickets	Root cause, fix PR, rotation confirmation, closure date	Engineering
Secrets manager configuration evidence	Access policies, audit logging enabled, secret rotation workflows	IAM/Platform
Exception register	Approved exceptions, compensating controls, expiry, approvals	GRC

This evidence directly supports the IA-5(7) expectation that unencrypted static authenticators are not embedded in applications or static storage. ¹

Common exam/audit questions and hangups

• “Show me how you prevent a developer from committing a secret.” Expectation: pipeline gates and scanning with documented escalation. ¹
• “What do you define as ‘static storage’?” If your answer is only “Git,” you will miss images, backups, and tickets. ¹
• “How do you handle secrets in CI?” Auditors commonly probe build logs, artifact retention, and injected variables. ¹
• “Do third parties provide code or images, and do you scan them?” They will treat third-party artifacts as in-scope if they run in your environment. ¹
• “Show rotation evidence for a leaked key.” Be ready with a real example and the closure trail. ¹

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Declaring ‘we don’t hardcode secrets’ without detection.
   Fix: Implement scanning and keep recurring results as evidence. ¹

2. Mistake: Treating base64 or “masked in UI” as encryption.
   Fix: Store secrets only in a secrets manager or encrypted store with managed keys and access controls; document what “encrypted” means internally. ¹

3. Mistake: Cleaning current code but ignoring git history, images, and artifacts.
   Fix: Include history, registries, and artifact retention locations in your scope map and remediation runbook. ¹

4. Mistake: Allowing sample configs with real credentials to persist in repos.
   Fix: Require .example configs with placeholders and enforce review checks for “real-looking” keys. ¹

5. Mistake: Exceptions with no expiry.
   Fix: Maintain an exception register with a forced renewal decision and a migration plan. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this control, so you should treat IA-5(7) primarily as an assessment and breach-risk driver rather than a control with a case-law playbook in this packet. ¹

Risk-wise, embedded unencrypted authenticators convert common exposures (repo access, CI compromise, artifact leakage, insider access, mis-shared files) into direct unauthorized access. In federal and contractor contexts, that can become a reportable incident, a failed assessment, or a contractual noncompliance finding depending on your environment and obligations. Keep your statements tied to your contracts and your system security plan. ¹

A practical execution plan (30/60/90-day)

You asked for speed; use this phased plan as an operator checklist. Timeboxes are labels only. ¹

First 30 days (Immediate controls and visibility)

• Assign control owner and publish the “no embedded secrets” standard mapped to IA-5(7). ¹
• Stand up secret scanning on your top repos and default branches; start collecting outputs as evidence. ¹
• Identify your approved secrets manager pattern and publish developer runbooks. ¹
• Start an exception register template (even if empty) so you can show governance. ¹

Next 60 days (Prevention in the SDLC)

• Add CI gates for secret findings on high-risk repos and build pipelines. ¹
• Expand scanning scope to container registries and IaC repos. ¹
• Run a focused remediation sprint: remove secrets, rotate credentials, and document closure trails. ¹
• Add third-party intake checks for code/images and update contract language or security requirements accordingly. ¹

Next 90 days (Sustained operations and audit readiness)

• Operationalize recurring evidence capture: scheduled scan reports, ticket metrics, exception reviews. ¹
• Validate secrets rotation capability for common secret types and ensure break-glass processes do not create static storage leakage. ¹
• Document the full control narrative in your SSP/control library and align it to assessment procedures. Daydream can centralize the owner, procedure, and evidence links so audits run on artifacts instead of meetings. ¹

Frequently Asked Questions

Does IA-5(7) ban all static authenticators?

No. It bans embedding unencrypted static authenticators in applications or static storage. You can still use static secrets if they are stored and managed securely (for example, in a secrets manager) and not hardcoded or left in cleartext files. ¹

Are environment variables considered “embedded” or “static storage”?

Environment variables injected at runtime are usually acceptable, but they become a problem if they are written into static places like committed .env files, CI job definitions stored in repos, or long-retained build logs. Treat the full pipeline as in scope, not just the runtime host. ¹

What about encrypted values in a config file committed to Git?

Encrypted-at-rest config can meet the “not unencrypted” part, but auditors will still ask about key management and access controls. Prefer secrets managers because they reduce key sprawl and provide clearer access logging and rotation workflows. ¹

Do API keys in mobile apps violate IA-5(7)?

Often yes, because anything shipped to a client device is effectively exposed and recoverable. Replace embedded keys with backend-mediated flows, short-lived tokens, or device-bound attestation patterns so the “secret” is not statically stored in the app. ¹

How do we prove compliance if we have thousands of repos?

Prove coverage by documenting scan scope, showing scheduled/recurring scan outputs, and sampling remediation records across teams. Auditors look for systematic detection plus a working remediation loop, not a one-time screenshot. ¹

How should we handle third-party code and images?

Treat them as in-scope artifacts. Require third-party security requirements that prohibit embedded unencrypted authenticators, scan delivered code/images before deployment, and keep intake scan results and remediation actions as evidence. ¹

Footnotes

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