Skip to main content
MuonPartners
Services
Architecture

Solution design and technology roadmapping

Solution AssessmentTechnology RoadmapsIntegration DesignSolution ArchitectureTechnical Design
Cyber Security

Security assessments, IAM, and compliance

AssessmentsIAMComplianceSecurity BaselineCyber Innovation
Network and Platform

Network architecture and cloud platforms

Network DesignCloud StrategyModernisation
Enterprise Architecture

Business-technology alignment

Business AlignmentPortfolio AnalysisGovernance
View all services
ProjectsCase StudiesInsightsToolsAbout
Contact Us

Services

Architecture
Solution AssessmentTechnology RoadmapsIntegration DesignSolution ArchitectureTechnical Design
Cyber Security
AssessmentsIAMComplianceSecurity BaselineCyber Innovation
Network and Platform
Network DesignCloud StrategyModernisation
Enterprise Architecture
Business AlignmentPortfolio AnalysisGovernance
ProjectsCase StudiesInsightsToolsAboutContact
Get in Touch
MuonPartners

Strategic technology consulting for Australian organisations navigating complexity.

Services

  • Architecture
  • Cyber Security
  • Network and Platform
  • Enterprise Architecture

Company

  • About
  • Products
  • Frameworks
  • Cross-Framework Mapping
  • Projects
  • Case Studies
  • Insights
  • Contact

Contact

  • [email protected]
  • Australia
  • LinkedIn

© 2026 Muon Partners. All rights reserved.

ABN 50 669 022 315 · A Muon Group company.

Privacy PolicyTerms of Service
  1. Frameworks
  2. >SP 800-53
  3. >System And Services Acquisition
  4. >SP800-53-SA-8(23)
SP800-53-SA-8(23)Active

Secure Defaults

Statement

Implement the security design principle of secure defaults in systems or system components.

Location

Control Family
System and Services Acquisition

Control Details

Identifier
SP800-53-SA-8(23)
Family
SA
Parent Control
SP800-53-SA-8

Organisation-Defined Parameters

sa-08.23_odp
systems or system components

Supplemental Guidance

The principle of secure defaults states that the default configuration of a system (including its constituent subsystems, components, and mechanisms) reflects a restrictive and conservative enforcement of security policy. The principle of secure defaults applies to the initial (i.e., default) configuration of a system as well as to the security engineering and design of access control and other security functions that follow a "deny unless explicitly authorized" strategy. The initial configuration aspect of this principle requires that any "as shipped" configuration of a system, subsystem, or system component does not aid in the violation of the security policy and can prevent the system from operating in the default configuration for those cases where the security policy itself requires configuration by the operational user.

Restrictive defaults mean that the system will operate "as-shipped" with adequate self-protection and be able to prevent security breaches before the intended security policy and system configuration is established. In cases where the protection provided by the "as-shipped" product is inadequate, stakeholders assess the risk of using it prior to establishing a secure initial state. Adherence to the principle of secure defaults guarantees that a system is established in a secure state upon successfully completing initialization. In situations where the system fails to complete initialization, either it will perform a requested operation using secure defaults or it will not perform the operation. Refer to the principles of continuous protection and secure failure and recovery that parallel this principle to provide the ability to detect and recover from failure.

The security engineering approach to this principle states that security mechanisms deny requests unless the request is found to be well-formed and consistent with the security policy. The insecure alternative is to allow a request unless it is shown to be inconsistent with the policy. In a large system, the conditions that are satisfied to grant a request that is denied by default are often far more compact and complete than those that would need to be checked in order to deny a request that is granted by default.

Assessment Objective

systems or system components implement the security design principle of secure defaults.

No cross-framework mappings available

← Back to System and Services Acquisition
System and Services Acquisition147 controls
SP800-53-SA-1Policy and ProceduresSP800-53-SA-2Allocation of ResourcesSP800-53-SA-3System Development Life CycleSP800-53-SA-3(1)Manage Preproduction EnvironmentSP800-53-SA-3(2)Use of Live or Operational DataSP800-53-SA-3(3)Technology RefreshSP800-53-SA-4Acquisition ProcessSP800-53-SA-4(1)Functional Properties of ControlsSP800-53-SA-4(2)Design and Implementation Information for ControlsSP800-53-SA-4(3)Development Methods, Techniques, and PracticesSP800-53-SA-4(4)Assignment of Components to SystemsSP800-53-SA-4(5)System, Component, and Service ConfigurationsSP800-53-SA-4(6)Use of Information Assurance ProductsSP800-53-SA-4(7)NIAP-approved Protection Profiles SP800-53-SA-4(8)Continuous Monitoring Plan for ControlsSP800-53-SA-4(9)Functions, Ports, Protocols, and Services in UseSP800-53-SA-4(10)Use of Approved PIV ProductsSP800-53-SA-4(11)System of RecordsSP800-53-SA-4(12)Data OwnershipSP800-53-SA-5System DocumentationSP800-53-SA-5(1)Functional Properties of Security ControlsSP800-53-SA-5(2)Security-relevant External System InterfacesSP800-53-SA-5(3)High-level DesignSP800-53-SA-5(4)Low-level DesignSP800-53-SA-5(5)Source CodeSP800-53-SA-6Software Usage RestrictionsSP800-53-SA-7User-installed SoftwareSP800-53-SA-8Security and Privacy Engineering PrinciplesSP800-53-SA-8(1)Clear AbstractionsSP800-53-SA-8(2)Least Common MechanismSP800-53-SA-8(3)Modularity and LayeringSP800-53-SA-8(4)Partially Ordered DependenciesSP800-53-SA-8(5)Efficiently Mediated AccessSP800-53-SA-8(6)Minimized SharingSP800-53-SA-8(7)Reduced ComplexitySP800-53-SA-8(8)Secure EvolvabilitySP800-53-SA-8(9)Trusted ComponentsSP800-53-SA-8(10)Hierarchical TrustSP800-53-SA-8(11)Inverse Modification ThresholdSP800-53-SA-8(12)Hierarchical ProtectionSP800-53-SA-8(13)Minimized Security ElementsSP800-53-SA-8(14)Least PrivilegeSP800-53-SA-8(15)Predicate PermissionSP800-53-SA-8(16)Self-reliant TrustworthinessSP800-53-SA-8(17)Secure Distributed CompositionSP800-53-SA-8(18)Trusted Communications ChannelsSP800-53-SA-8(19)Continuous ProtectionSP800-53-SA-8(20)Secure Metadata ManagementSP800-53-SA-8(21)Self-analysisSP800-53-SA-8(22)Accountability and TraceabilitySP800-53-SA-8(23)Secure DefaultsSP800-53-SA-8(24)Secure Failure and RecoverySP800-53-SA-8(25)Economic SecuritySP800-53-SA-8(26)Performance SecuritySP800-53-SA-8(27)Human Factored SecuritySP800-53-SA-8(28)Acceptable SecuritySP800-53-SA-8(29)Repeatable and Documented ProceduresSP800-53-SA-8(30)Procedural RigorSP800-53-SA-8(31)Secure System ModificationSP800-53-SA-8(32)Sufficient DocumentationSP800-53-SA-8(33)MinimizationSP800-53-SA-9External System ServicesSP800-53-SA-9(1)Risk Assessments and Organizational ApprovalsSP800-53-SA-9(2)Identification of Functions, Ports, Protocols, and ServicesSP800-53-SA-9(3)Establish and Maintain Trust Relationship with ProvidersSP800-53-SA-9(4)Consistent Interests of Consumers and ProvidersSP800-53-SA-9(5)Processing, Storage, and Service LocationSP800-53-SA-9(6)Organization-controlled Cryptographic KeysSP800-53-SA-9(7)Organization-controlled Integrity CheckingSP800-53-SA-9(8)Processing and Storage Location — U.S. JurisdictionSP800-53-SA-10Developer Configuration ManagementSP800-53-SA-10(1)Software and Firmware Integrity VerificationSP800-53-SA-10(2)Alternative Configuration Management ProcessesSP800-53-SA-10(3)Hardware Integrity VerificationSP800-53-SA-10(4)Trusted GenerationSP800-53-SA-10(5)Mapping Integrity for Version ControlSP800-53-SA-10(6)Trusted DistributionSP800-53-SA-10(7)Security and Privacy RepresentativesSP800-53-SA-11Developer Testing and EvaluationSP800-53-SA-11(1)Static Code AnalysisSP800-53-SA-11(2)Threat Modeling and Vulnerability AnalysesSP800-53-SA-11(3)Independent Verification of Assessment Plans and EvidenceSP800-53-SA-11(4)Manual Code ReviewsSP800-53-SA-11(5)Penetration TestingSP800-53-SA-11(6)Attack Surface ReviewsSP800-53-SA-11(7)Verify Scope of Testing and EvaluationSP800-53-SA-11(8)Dynamic Code AnalysisSP800-53-SA-11(9)Interactive Application Security TestingSP800-53-SA-12Supply Chain ProtectionSP800-53-SA-12(1)Acquisition Strategies / Tools / MethodsSP800-53-SA-12(2)Supplier ReviewsSP800-53-SA-12(3)Trusted Shipping and WarehousingSP800-53-SA-12(4)Diversity of SuppliersSP800-53-SA-12(5)Limitation of HarmSP800-53-SA-12(6)Minimizing Procurement TimeSP800-53-SA-12(7)Assessments Prior to Selection / Acceptance / UpdateSP800-53-SA-12(8)Use of All-source IntelligenceSP800-53-SA-12(9)Operations SecuritySP800-53-SA-12(10)Validate as Genuine and Not AlteredSP800-53-SA-12(11)Penetration Testing / Analysis of Elements, Processes, and ActorsSP800-53-SA-12(12)Inter-organizational AgreementsSP800-53-SA-12(13)Critical Information System ComponentsSP800-53-SA-12(14)Identity and TraceabilitySP800-53-SA-12(15)Processes to Address Weaknesses or DeficienciesSP800-53-SA-13TrustworthinessSP800-53-SA-14Criticality AnalysisSP800-53-SA-14(1)Critical Components with No Viable Alternative SourcingSP800-53-SA-15Development Process, Standards, and ToolsSP800-53-SA-15(1)Quality MetricsSP800-53-SA-15(2)Security and Privacy Tracking ToolsSP800-53-SA-15(3)Criticality AnalysisSP800-53-SA-15(4)Threat Modeling and Vulnerability AnalysisSP800-53-SA-15(5)Attack Surface ReductionSP800-53-SA-15(6)Continuous ImprovementSP800-53-SA-15(7)Automated Vulnerability AnalysisSP800-53-SA-15(8)Reuse of Threat and Vulnerability InformationSP800-53-SA-15(9)Use of Live DataSP800-53-SA-15(10)Incident Response PlanSP800-53-SA-15(11)Archive System or ComponentSP800-53-SA-15(12)Minimize Personally Identifiable InformationSP800-53-SA-15(13)Logging SyntaxSP800-53-SA-16Developer-provided TrainingSP800-53-SA-17Developer Security and Privacy Architecture and DesignSP800-53-SA-17(1)Formal Policy ModelSP800-53-SA-17(2)Security-relevant ComponentsSP800-53-SA-17(3)Formal CorrespondenceSP800-53-SA-17(4)Informal CorrespondenceSP800-53-SA-17(5)Conceptually Simple DesignSP800-53-SA-17(6)Structure for TestingSP800-53-SA-17(7)Structure for Least PrivilegeSP800-53-SA-17(8)OrchestrationSP800-53-SA-17(9)Design DiversitySP800-53-SA-18Tamper Resistance and DetectionSP800-53-SA-18(1)Multiple Phases of System Development Life CycleSP800-53-SA-18(2)Inspection of Systems or ComponentsSP800-53-SA-19Component AuthenticitySP800-53-SA-19(1)Anti-counterfeit TrainingSP800-53-SA-19(2)Configuration Control for Component Service and RepairSP800-53-SA-19(3)Component DisposalSP800-53-SA-19(4)Anti-counterfeit ScanningSP800-53-SA-20Customized Development of Critical ComponentsSP800-53-SA-21Developer ScreeningSP800-53-SA-21(1)Validation of ScreeningSP800-53-SA-22Unsupported System ComponentsSP800-53-SA-22(1)Alternative Sources for Continued SupportSP800-53-SA-23SpecializationSP800-53-SA-24Design For Cyber Resiliency