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-17(7)
SP800-53-SA-17(7)Active

Structure for Least Privilege

Statement

Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate controlling access with least privilege.

Location

Control Family
System and Services Acquisition

Control Details

Identifier
SP800-53-SA-17(7)
Family
SA
Parent Control
SP800-53-SA-17

Supplemental Guidance

The principle of least privilege states that each component is allocated sufficient privileges to accomplish its specified functions but no more (see SA-8(14) ). Applying the principle of least privilege limits the scope of the component’s actions, which has two desirable effects. First, the security impact of a failure, corruption, or misuse of the system component results in a minimized security impact. Second, the security analysis of the component is simplified. Least privilege is a pervasive principle that is reflected in all aspects of the secure system design. Interfaces used to invoke component capability are available to only certain subsets of the user population, and component design supports a sufficiently fine granularity of privilege decomposition. For example, in the case of an audit mechanism, there may be an interface for the audit manager, who configures the audit settings; an interface for the audit operator, who ensures that audit data is safely collected and stored; and, finally, yet another interface for the audit reviewer, who only has a need to view the audit data that has been collected but no need to perform operations on that data.

In addition to its manifestations at the system interface, least privilege can be used as a guiding principle for the internal structure of the system itself. One aspect of internal least privilege is to construct modules so that only the elements encapsulated by the module are directly operated upon by the functions within the module. Elements external to a module that may be affected by the module’s operation are indirectly accessed through interaction (e.g., via a function call) with the module that contains those elements. Another aspect of internal least privilege is that the scope of a given module or component includes only those system elements that are necessary for its functionality, and the access modes to the elements (e.g., read, write) are minimal.

Assessment Objective

the developer of the system, system component, or system service is required to structure security-relevant hardware, software, and firmware to facilitate controlling access with least privilege.

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