SA-8(23): Secure Defaults

SA-8(23) requires you to build and configure systems so the default state is the most secure state that still allows intended business use. Operationally, that means defining secure baseline configurations, making them the “out-of-box” defaults for build pipelines and products, and forcing explicit, documented approvals for any weaker settings. ¹

Key takeaways:

• Secure defaults must be implemented in the system design and in the way you ship/build/configure components, not only documented in policy. ¹
• You need a repeatable mechanism: hardened baselines + automated enforcement + exception workflow with owner, risk acceptance, and expiry.
• Auditors will look for proof the defaults are secure in practice: “gold images,” IaC modules, configuration scans, and change records tied to approvals.

SA-8(23): Secure Defaults is a design and engineering control that compliance teams can operationalize through configuration management. The control language is short, but the audit expectation is not: you must be able to show that new systems, system components, and common deployments start life in a hardened posture without relying on an engineer to “remember the right settings.”

For a CCO or GRC lead, the fastest path is to treat secure defaults as a product and platform requirement: define what “secure by default” means for each major technology class you run (cloud accounts, Kubernetes, endpoints, databases, SaaS admin consoles, applications), then enforce it through standard build artifacts (images, templates, Terraform modules, Helm charts, golden AMIs, MDM profiles) plus an exception process that is harder than doing the secure thing.

This page focuses on requirement-level execution: who owns what, the minimum steps to make the control real, and the evidence bundle you should retain for assessments mapped to NIST SP 800-53 Rev. 5. ²

Regulatory text

Requirement (verbatim): “Implement the security design principle of secure defaults in [systems or system components].” ¹

What the operator must do: ensure that default configurations and initial states reduce attack surface and prevent unsafe operation without deliberate, authorized changes. In practice, this means:

• Defaults deny unnecessary access (closed ports, least-privileged roles, minimal network exposure).
• Defaults enable protective controls (logging, encryption where available, MFA, secure session settings).
• Defaults require an explicit decision to weaken security, recorded through change control and risk acceptance.

Plain-English interpretation (what “secure defaults” means in real programs)

Secure defaults means: if someone deploys a new component using your standard processes, it should come up secure without extra steps. Secure defaults is about “starting state” and “path of least resistance.” If the easiest path is insecure (public storage buckets, admin accounts without MFA, permissive security groups, verbose secrets in env vars), you will fail this control even if you have policies telling people not to do those things.

For auditors and customer due diligence, the strongest demonstration is automation: baseline templates plus guardrails that prevent drift. A PDF standard helps, but doesn’t prove your defaults are what engineers actually ship.

Who it applies to (entity and operational context)

SA-8(23) is relevant to:

• Federal information systems and programs aligned to NIST SP 800-53 Rev. 5. ²
• Contractor systems handling federal data, including cloud-hosted platforms, internal tooling, and SDLC pipelines where your organization builds, configures, or deploys system components. ²

Operationally, it applies anywhere your teams create “new instances” of technology:

• Cloud account/subscription vending
• Network segments, security groups, firewalls
• IAM roles, service accounts, default permissions
• Endpoint baselines (MDM, CIS-aligned policies if you use them internally)
• Container/Kubernetes clusters and namespaces
• Databases, message queues, storage services
• Application feature flags, admin consoles, default user roles, password/MFA/session policy settings
• CI/CD templates and build runners

If a third party hosts part of the stack (SaaS, PaaS), SA-8(23) still shows up as: “Did you configure the service securely by default, and do your provisioning scripts enforce that configuration?”

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

Use this as a buildable runbook. The goal is to convert a principle into enforceable defaults with auditable traceability.

Step 1: Name an owner and define control boundaries

• Assign an engineering owner (often Platform/Infrastructure) and a GRC owner (control governance).
• Define which “systems or system components” are in scope for secure defaults: prioritize the components that are most frequently provisioned and most exposed (IAM, network, data stores, container platforms, CI/CD templates).

Operator tip: If you don’t define scope, teams will claim “secure defaults is subjective.” Make it concrete by technology class.

Step 2: Define “secure default baselines” by technology class

Create a baseline standard for each class with:

• Required default settings (example categories: authentication, authorization, network exposure, encryption, logging, admin access).
• Prohibited defaults (example: public-by-default access, shared admin credentials, broad wildcard permissions).
• Minimum versioning/patch posture expectations for base images and runtime.

Keep the baseline short and testable. “Should” language becomes audit pain. Prefer “must” with a measurable check.

Step 3: Implement defaults in build artifacts (where it actually matters)

Translate the baseline into the artifacts engineers use every day:

• Golden images (VM and container base images)
• Infrastructure-as-code modules
• Secure “starter” repos and CI/CD templates
• Kubernetes admission policies or policy-as-code rules
• SaaS provisioning scripts (SCIM, SSO enforcement, default role mappings)
• MDM profiles and endpoint baselines

A secure defaults control that lives only in a wiki is not operational.

Step 4: Add preventive guardrails (block insecure defaults)

Secure defaults fails if someone can easily ship an insecure deployment. Add controls such as:

• Policy-as-code checks in CI/CD for IaC changes
• Cloud configuration rules that detect and block insecure resources at creation time where possible
• Minimum-required settings (MFA for admins, logging enabled) enforced by automation

Where blocking is not feasible, require rapid detection plus a forced remediation workflow tied to accountable owners.

Step 5: Create an exception process that is explicit and time-bounded

You need a path for legitimate business needs (legacy integration, vendor constraints), but it must be controlled:

• Written exception request with business justification
• Security review and compensating controls
• Approval authority (security + system owner)
• Risk acceptance record
• Expiration and re-review trigger

This is where many programs break: exceptions become permanent defaults. Treat exceptions as temporary deviations that must be actively renewed.

Step 6: Prove the defaults stay secure (control health checks)

Secure defaults is not a one-time design decision. Build recurring checks:

• Periodic scans for drift against baselines
• Spot checks of newly provisioned resources
• Metrics that show coverage and exceptions (qualitative is fine if you can’t reliably quantify yet)
• Remediation tracking to verified closure

Daydream fit: capture the “control card” (objective, owner, trigger events, steps, exception rules) and attach the minimum evidence bundle per cycle so audits don’t turn into screenshot hunts.

Required evidence and artifacts to retain

Auditors and customer assessors typically want evidence across design, implementation, and operation. Keep an evidence bundle per in-scope platform:

Governance artifacts

• Secure Defaults standard (by technology class) with version history and approvals
• Control card/runbook: owner, scope, triggers (new system, major change), exception rules
• Exception register with approvals, compensating controls, and expiry dates

Technical implementation artifacts

• Golden images / base container image definitions and hardening notes
• IaC modules and “blessed” templates showing secure settings as defaults
• Policy-as-code rules (source repo link, change history)
• CI/CD pipeline configs that enforce baseline checks

Operating evidence

• Configuration scan outputs or compliance reports against baselines
• Samples of newly deployed components showing default settings applied
• Change records for baseline changes (who approved, what changed, why)
• Tickets showing remediation to closure for drift or insecure deployments

Retention location matters. Store artifacts in systems with access controls and an audit trail (GRC tool, ticketing system, version control).

Common exam/audit questions and hangups

Expect these questions, and pre-answer them in your control narrative:

1. “Show me your secure defaults.” They will ask for concrete defaults in at least one environment, not a policy statement.
2. “How do you ensure engineers can’t bypass defaults?” If bypass is possible, show detection, approval, and remediation controls.
3. “How do secure defaults apply to SaaS?” Provide your standard SaaS configuration baseline and provisioning scripts.
4. “What about legacy systems?” Show an exception with compensating controls and a migration plan.
5. “Who approves weakening a default?” If you can’t name an approver role and show evidence, the control is weak.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Treating secure defaults as a policy-only requirement

Fix: Put defaults into templates/images/modules. Policy should reference the code artifacts as the source of truth.

Mistake 2: One baseline for everything

Fix: Use baseline-by-class (cloud, Kubernetes, endpoints, databases). One-size baselines get ignored because they don’t map to real settings.

Mistake 3: No exception expiry

Fix: Require expiration and re-review. If exceptions never expire, insecure becomes normal.

Mistake 4: Defaults exist, but no enforcement

Fix: Add preventive checks in CI/CD and configuration rules in runtime environments. If enforcement is delayed until an annual review, you’ll accumulate drift.

Mistake 5: No evidence bundle

Fix: Define the minimum artifacts you will retain each cycle. Daydream-style evidence checklists prevent gaps when staff changes.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-8(23). Practically, secure defaults ties directly to incident risk: misconfigurations and overly permissive defaults are common root causes in security events, and examiners often treat repeated misconfiguration findings as a control design failure rather than isolated mistakes.

For federal and federal-adjacent environments, weak defaults also create downstream compliance failures across access control, configuration management, and audit logging expectations because insecure defaults cascade into many other controls.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Assign owners and document scope by technology class.
• Write secure default baseline requirements for the top classes you provision most.
• Inventory current templates/images/modules and identify where defaults are set today.
• Define your evidence bundle and where it will live (repo paths, ticketing, GRC records).

Days 31–60 (implement and enforce)

• Update golden images and IaC modules to embed secure defaults.
• Add CI checks to prevent insecure parameters (example categories: public exposure, wildcard IAM, logging disabled).
• Stand up an exception workflow with approvers, compensating control guidance, and expirations.
• Run a pilot on one platform (for example, cloud network + IAM) and collect evidence.

Days 61–90 (operate and prove)

• Expand defaults to remaining in-scope platforms.
• Start recurring drift checks and track remediation to closure.
• Produce an “audit-ready” package: baseline docs, implementation artifacts, sample deployment evidence, exception register.
• Run an internal control health check and document gaps and fixes.

Frequently Asked Questions

Does SA-8(23) mean every default must be “most secure possible,” even if it breaks usability?

No. The control requires secure defaults as a design principle, which in practice means secure by default while still supporting intended use. Where usability requires a weaker setting, treat it as an exception with approval and compensating controls. ¹

How do we apply secure defaults to SaaS products we don’t fully control?

Define a SaaS configuration baseline (SSO/MFA, role defaults, logging, data sharing settings) and enforce it through onboarding checklists and provisioning scripts. Retain admin console configuration evidence and change history.

What evidence is strongest for auditors: policies or technical controls?

Technical evidence is stronger because it shows the default state in practice: golden images, IaC modules, and CI guardrails. Keep the policy, but point it to the code artifacts as the implementing mechanism.

Are exceptions allowed under SA-8(23)?

Yes, but they must be explicit. Require documented rationale, approval, compensating controls, and an expiration date so insecure settings don’t silently become permanent defaults.

How do we show “secure defaults” for internally developed applications?

Document and test default app settings: default roles, session timeouts, password/MFA requirements, logging enabled, and secure configuration flags. Demonstrate that new deployments start with those settings via release templates or application config management.

We already have CIS benchmarks. Is that enough?

CIS benchmarks can inform baselines, but SA-8(23) still requires you to make those settings the default in your build and deployment paths. Auditors will look for how the benchmark maps into your images, templates, and enforcement workflow. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5