Auditors ask Mac teams to prove CIS, NIST SP 800-53, 800-171 or STIG compliance, and most teams answer with a spreadsheet of hand-built configuration profiles that drift from the benchmark with every macOS release. The macOS Security Compliance Project (mSCP), run by NIST with NASA, DISA and Los Alamos National Laboratory and a community of contributors, turns those frameworks into one library of machine-readable rules and generates the configuration profiles, Declarative Device Management assets, compliance scripts and documentation for a chosen baseline. This guide explains how mSCP is structured, how it relates to the CIS Apple macOS Benchmarks, how to tailor and deploy a baseline, how to produce assessment evidence and where teams go wrong. It is for Mac administrators, compliance leads and assessors. Status and versions were checked on 27 October 2026; the general macOS control set is covered in the macOS Security Guide for Enterprises.
Key takeaways
- One rule library, many frameworks. Each mSCP rule carries references to NIST SP 800-53 Rev 5, 800-171 Rev 3, CIS Benchmark and CIS Controls, DISA STIG, CMMC and others, so a single deployment can be reported against several frameworks.
- Baselines are generated, not hand-written. A baseline is a list of rules selected by tag (for example
cis_lvl1or800-53r5_moderate), and the tooling turns it into profiles, a compliance script and a guide. - Tailor, do not apply blindly. NIST describes its 800-53 baselines as "a catalog, not a checklist or benchmark"; organisation-defined values (ODVs) and tailoring exist so you set values such as password length deliberately.
- Exemptions are first-class. The compliance script reads an audit preference file in which each rule can be marked exempt with a reason, and counts exempt rules separately, which gives auditors a documented trail instead of silent gaps.
- Track the release cadence. mSCP 2.0 (main branch) supports macOS 27 and unifies macOS, iOS and iPadOS and visionOS, while per-release branches such as
tahoehold earlier macOS content; regenerate with every major macOS release.
What it is and who it applies to
mSCP is an open-source project (licensed CC BY 4.0) whose security rules are derived from NIST SP 800-53 Rev 5. It is the technical implementation of NIST SP 800-219, Automated Secure Configuration Guidance from the macOS Security Compliance Project. The current final publication on the NIST CSRC site is Rev. 1 (July 2023), which added tailoring; the project README refers to Rev. 2, so check CSRC for the latest status before citing a revision in audit documentation. Apple acknowledges the project on its Apple Platform Certifications pages.
| Who | Why mSCP applies | Typical baseline |
|---|---|---|
| US federal civilian agencies | The project points agencies to the National Checklist Program required by NIST SP 800-70 | 800-53r5 low, moderate or high |
| Defence and national security systems | DISA participates and the rules carry STIG and CNSSI 1253 references | DISA STIG, CNSSI 1253 |
| Defence suppliers handling controlled unclassified information | Rules map to SP 800-171 Rev 3 and CMMC practices | 800-171, cmmc_lvl2 |
| Any organisation using CIS | CIS Benchmarks Level 1 and 2 and CIS Controls v8 baselines are maintained with CIS's permission and support | cis_lvl1, cis_lvl2, cisv8 |
| Healthcare and other sectors | Additional frameworks include HICP (US health sector), NLMAPGOV (Netherlands) and BSI Indigo (Germany, iOS) | Sector baselines |
The CIS Apple macOS Benchmarks themselves are published by CIS (the current list includes macOS 26 Tahoe 1.1.0 and macOS 15 Sequoia 2.1.0) and are free in PDF for non-commercial use. mSCP's CIS baselines implement those benchmarks as rules; the benchmark PDF remains the authoritative statement of each recommendation. See the CIS Benchmarks Guide.
Structure and key requirements
Rules
Each rule is a YAML file with a consistent structure. Taking os_sip_enable (Ensure System Integrity Protection is Enabled) as an example:
| Field | Content | Example from os_sip_enable |
|---|---|---|
id, title, discussion | What the rule requires and why | SIP must be enabled |
check and result | Shell command that tests compliance and the expected output | csrutil status piped to a count of the enabled message, expecting integer 1 |
fix | Remediation, or a note that a configuration profile implements it | csrutil enable from Recovery |
references | Framework identifiers | 800-53r5 AC-3, AU-9, CM-5, SI-7 and others; CIS benchmark 5.1.2 (level 1); CIS Controls v8 2.3, 2.6, 10.5; DISA STIG APPL-26-005001; 800-171r3 03.01.02 and others |
tags | Which baselines include the rule | 800-53r5_low to high, cis_lvl1, cis_lvl2, stig, cmmc_lvl2 and more |
odv | Organisation-defined value with framework-specific defaults | For pwpolicy_minimum_length_enforce: recommended 15, CIS 15, STIG 14 |
mobileconfig_info and ddm_info | The profile payload or declaration that enforces the setting | com.apple.mobiledevice.passwordpolicy minLength, or DDM com.apple.configuration.passcode.settings MinimumLength |
Baselines and outputs
- Baseline files: each baseline YAML (for example
cis_lvl1.yaml, titled for the CIS Apple macOS 26.0 Tahoe v1.1.0 Benchmark Level 1) lists rules by section such as auditing, authentication, operating system, password policy and system settings. - Configuration profiles: generated per payload domain, optionally as a consolidated profile, and can be signed.
- DDM assets: declarations for device management services that support declarative delivery. See the Apple Declarative Device Management and Managed Device Attestation Guide.
- Compliance script: a shell script that runs every check, optionally remediates what profiles cannot, and writes results.
- Documentation and spreadsheet: HTML, PDF or Markdown guides and an Excel export listing each rule, check, fix and references, which become audit artefacts.
Identity and NHI requirements
A large share of the rules are about who can sign in and with what rights, which is where Mac fleets most often fail audits.
| Area | Example rules | What to decide |
|---|---|---|
| Password policy | pwpolicy_minimum_length_enforce, pwpolicy_account_lockout_enforce | ODVs for length and lockout; whether passwords are the primary factor at all |
| Smart card and phishing-resistant sign-in | auth_smartcard_enforce, auth_pam_su_smartcard_enforce | Required for STIG-style environments; plan PIV or derived credential issuance first |
| Root and privileged use | os_root_disable, os_sudo_timeout_configure, os_sudoers_timestamp_type_configure, os_sudo_log_enforce | How administrators elevate, how long sudo credentials are cached and how elevation is logged |
| Remote access | system_settings_ssh_disable, auth_ssh_password_authentication_disable | Whether SSH is needed; if so, key-only authentication and who holds the keys |
| Guest and shared access | system_settings_guest_account_disable | No anonymous local sessions on managed Macs |
- Management service accounts: the baselines harden the Mac, but the credentials that manage it sit outside the rules: the MDM server's API clients, the managed local administrator account and its rotation, the Bootstrap Token escrowed to MDM, and any SSH keys used by automation. Inventory and own them as non-human identities. See the Non-Human Identity (NHI) Guide.
- Directory and single sign-on: rules that assume smart cards or local password policy interact with Platform SSO and directory binding choices. Decide the sign-in model before tailoring. See the macOS Platform SSO and Directory Binding Guide.
- Scripts that run as root: the compliance script runs with administrative privileges and can remediate; deliver it through the MDM or management agent only, sign or hash-check it, and restrict who can change it.
Implementation steps
- Choose the framework and branch: pick the baseline your obligation requires (for example
cis_lvl1or800-53r5_moderate) and the branch that matches your fleet's macOS version. mSCP 2.0 on the main branch covers macOS 27; older per-release branches such astahoeserve macOS 26. - List and generate the baseline: in the per-release branches,
generate_baseline.py -llists tags and-k <tag>builds a baseline. In mSCP 2.0 the equivalent ismscp baseline -landmscp baseline -k <tag>; legacy baselines can be migrated with-m. - Tailor: run the tailoring option (
-t) to include or exclude rules and set ODVs, recording why each deviation exists. Keep the tailored baseline YAML in version control. - Generate artefacts: use the guidance generator with
-p(profiles),-s(compliance script),-x(spreadsheet) and, where your MDM supports it, the DDM option. Use the hash or signing option for profiles if your MDM does not sign them. - Review conflicts with your MDM: compare generated payloads with profiles already deployed; two profiles setting the same key differently produce unpredictable results.
- Pilot: deploy to a test group covering each hardware type and user persona, run the compliance script with
--check, and fix breakage (for example, smart card enforcement on users without cards) before wider rollout. - Roll out in rings: IT, then early adopters, then the fleet. Run
--checkon a schedule from the management tool; use--fixor--cfc(check, fix, check) only for rules the profiles cannot enforce. - Regenerate per macOS release: new releases add, change and retire rules. Regenerate from the new branch, diff against the previous baseline, and re-pilot before upgrading the fleet.
- Rollback: remove or scope down the generated profiles in MDM; settings applied only by
--fixneed a reverse change, so prefer profiles for anything you may need to undo quickly.
Decision guidance
- CIS or 800-53: commercial organisations usually start from CIS Level 1, which is designed to be practical; regulated US federal and defence environments start from the 800-53, STIG or 800-171 baseline their authorisation requires.
- Level 1 or Level 2: Level 2 adds stricter settings with more user impact; apply it to high-risk roles rather than the whole fleet.
- Small vs large estates: a small team can generate profiles and the script once per release and upload them to MDM; a large estate should automate generation, diffing and ODV management in a pipeline and feed results into the compliance dashboard.
- mSCP or a vendor tool: several MDM and compliance vendors build on mSCP content. Whichever you use, ask which mSCP version and branch it tracks.
Evidence and assessment
| Artefact | Location or source | What it proves |
|---|---|---|
| Tailored baseline YAML and change history | Version control | Which rules and values were chosen, by whom and why |
| Generated guide and spreadsheet | Guidance generator output | The control-by-control statement of what is configured, with framework references |
| Audit preferences and exemptions | /Library/Preferences/org.<baseline>.audit.plist with exempt and exempt_reason per rule | Approved deviations, scoped per device |
| Compliance log | /Library/Logs/<baseline>_baseline.log and unified log entries prefixed mSCP: | Each rule's pass, fail or exemption, with timestamps |
| Statistics | Compliance script --stats, --compliant, --non_compliant | Counts per device for dashboards |
| MDM inventory and profile status | Device management service | That the profiles were delivered and installed |
- Exemptions: the generated script skips remediation for exempt rules and logs the reason. Note that its compliance percentage counts exempt rules with compliant ones, so report exemptions separately or the score overstates the posture.
- Central collection: push results into the MDM's extension attributes or your SIEM so assessors see fleet-wide evidence, not a single machine's log. See the macOS Detection and Response Guide.
- Assessment method: for 800-53 and 800-171 assessments, map each rule's references to the assessment objectives and keep the rule's check command as the test procedure. See the NIST SP 800-53A Guide and the NIST SP 800-171A Rev 3 Assessment Guide.
Metrics
- Fleet compliance: percentage of rules passing per device, reported without exemptions counted as passes.
- Exemption volume: number of exempt rules per device and fleet-wide, each with an owner and expiry.
- Check freshness: percentage of devices with a compliance check in the last seven days.
- Release lag: days between a major macOS release and deployment of the regenerated baseline.
- Drift: number of rules that failed after previously passing, investigated as configuration change events.
Mapping to other frameworks
| Framework | How mSCP covers it | Example references (os_sip_enable) |
|---|---|---|
| NIST SP 800-53 Rev 5 | Source of all rules; low, moderate and high baselines | AC-3, AU-9, CM-5, SI-7 |
| NIST SP 800-171 Rev 3 and CMMC | 800-171 and cmmc_lvl2 baselines | 03.01.02, 03.04.05; CMMC SI.L1-3.14.1 |
| CIS Apple macOS Benchmark | cis_lvl1 and cis_lvl2 | 5.1.2 (level 1) |
| CIS Controls v8 | cisv8 baseline | 2.3, 2.6, 10.5 |
| DISA STIG | STIG references and ODV defaults | APPL-26-005001 |
| CNSSI 1253 | Low, moderate and high baselines | Via 800-53 references |
| NIST CSF 2.0 | Not a native mSCP baseline; map through 800-53 | PR.PS-01 configuration management |
| ISO/IEC 27001:2022 Annex A | Not a native baseline; use mSCP output as evidence for A.8.9 Configuration management and A.8.1 User endpoint devices | Not applicable |
For the frameworks themselves, see the NIST SP 800-53 Guide, the NIST SP 800-171 and CMMC 2.0 Guide and the DISA STIG Guide.
Common pitfalls
- Applying the whole catalogue: deploying every rule in an 800-53 baseline without tailoring breaks workflows, which NIST warns against by calling the list a catalogue rather than a checklist.
- Stale branch: generating from last year's branch after a macOS upgrade leaves rules that check settings Apple has renamed or removed, producing false failures or silent gaps.
- Scores inflated by exemptions: exempt rules count towards the script's compliance percentage, so a fleet with many exemptions can report a high score.
- Profile conflicts: generated profiles layered on top of older hand-made ones set the same keys to different values, and nobody can say which wins.
- Remediation instead of enforcement: relying on
--fixfor settings a profile could enforce lets users or software change them back between runs. - Ignoring the management plane: a perfectly compliant Mac is still exposed if the MDM API credentials, managed admin password or escrowed Bootstrap Tokens are poorly protected. See the Stryker Intune wiper attack, where a hijacked administrator used the device management service against the fleet.
Practitioner checklist
- Select the baseline your obligation requires and the mSCP branch matching your macOS version.
- Tailor rules and ODVs, recording each deviation, and keep the baseline YAML in version control.
- Generate profiles, DDM assets where supported, the compliance script and the spreadsheet from that baseline.
- Remove conflicting legacy profiles before deploying generated ones.
- Pilot across hardware types and personas, then roll out in rings.
- Run the compliance script on a schedule and collect results centrally.
- Manage exemptions in the audit preferences with reasons, owners and expiry, and report them separately from passes.
- Regenerate, diff and re-pilot for every major macOS release.
- Protect MDM API credentials, managed admin accounts and escrowed tokens as privileged non-human identities.
Standards and references
- NIST: SP 800-219 Rev. 1 Automated Secure Configuration Guidance from the macOS Security Compliance Project
- NIST: macOS Security Compliance Project repository
- NIST: macOS Security Compliance Project website
- CIS: Apple macOS Benchmarks
- NIST: SP 800-53 Rev. 5
- NIST: SP 800-171 Rev. 3
- Apple: Apple Platform Security guide
Related NHI Mgmt Group resources: macOS Security Guide for Enterprises · Apple Platform Security Explained · Jamf Guide · Endpoint Hardening Checklist