macOS test plan
What to test on a macOS release so the baseline still holds: the checks of Apple macOS 26 (Tahoe) V1R4 and macOS 26.0: Tahoe Guidance, Revision 3.0 (cf656e8), by area
Derived from
STIG Apple macOS 26 (Tahoe) V1R4
mSCP macOS 26.0: Tahoe Guidance, Revision 3.0 (cf656e8)
Checks 281 tested: 233 from the publishers' procedures, 48 from the owner's templates
By area Hardware root of trust and secure enclave 11, Platform SSO and identity 13, Authentication 74, Disk encryption 9, MDM enrolment 4, Updates and release changes 9, Network 50, Browsers 2, Logging and audit 34, Everything else 75
Templates 12
Conditional Access holds on the new release 3 steps · Authentication · conditional-access.yaml Whatever the platform, the new OS release must still satisfy the compliance and device-state signals the Conditional Access policies ask for.
FileVault enforced with the recovery key escrowed to the MDM 4 steps · Disk encryption · filevault-escrow.yaml The mSCP rule system_settings_filevault_enforce and its FileVault supplemental describe the profile; this template tests that the escrow still works on the new release.
The application firewall on macOS 2 steps · Network · firewall-macos.yaml Joins the plan only when an applied rule names the firewall. System Integrity Protection and Gatekeeper are in the hardware root of trust template.
Secure Enclave, secure boot and the signed system on a Mac 7 steps · Hardware root of trust and secure enclave · hardware-root-macos.yaml The chain from the Secure Enclave up. Run on a Mac enrolled the way the fleet is enrolled, after the baseline is applied. An Intel Mac without a T2 chip has no Secure Enclave and no secure boot; for it only the SIP, FileVault and Gatekeeper steps apply (the step applicability says so).
What a macOS release changes that the baseline relies on 5 steps · Updates and release changes · macos-release-checks.yaml Each step applies from the release that introduced the behaviour, and the Intel steps only to Intel Macs; the version and hardware you chose rule the others out.
Automated enrolment and the baseline profiles on a wiped device 3 steps · MDM enrolment · mdm-enrolment.yaml The first thing to test on a new release is that a wiped device enrols without a hand on it and receives the baseline.
Platform SSO with Microsoft Entra ID on a Mac 6 steps · Platform SSO and identity · platform-sso-entra-macos.yaml Microsoft supports macOS 13 and strongly recommends 14 or later; Company Portal must be 5.2404.0 or later before the profile is targeted. Test with a wiped Mac enrolled through Automated Device Enrollment and a test account under a Conditional Access policy that requires a compliant device. The authentication method the profile sets decides the steps; the Secure Enclave method needs a Secure Enclave, so the hardware you chose rules a step in or out.
Smart card (PIV or CAC) sign-in on macOS 4 steps · Authentication · smartcard-macos.yaml Joins the plan only when an applied rule enforces smart card authentication (mSCP auth_smartcard_enforce and the STIG rules it joins). Test with a provisioned PIV or CAC card and its reader.
SSH server hardening on macOS 3 steps · Network · ssh-macos.yaml Joins the plan only when an applied rule names SSH (the mSCP os_sshd_* rules and the STIG rules they join). If the baseline turns Remote Login off, the first step is the test and the rest do not apply.
Platform single sign-on on a Jamf-managed Mac, in each browser 4 steps · Authentication · sso-jamf-browsers.yaml Platform SSO needs the identity provider's extension (for Microsoft Entra, the Enterprise SSO plug-in) and a Platform SSO payload from the MDM. Test on the new macOS release with a device enrolled through Automated Device Enrollment.
Jamf Connect at the login window, with the identity provider's password kept in sync 4 steps · Platform SSO and identity · sso-jamf-connect.yaml For fleets that use Jamf Connect instead of (or before) Platform SSO. Test with Jamf Connect's login window and menu bar app configured for your identity provider (Microsoft Entra, Okta, Google) on a Mac enrolled in Jamf Pro.
Kerberos SSO extension against Active Directory 3 steps · Platform SSO and identity · sso-kerberos-extension.yaml For organisations with on-premises Active Directory. The MDM deploys an Extensible Single Sign-On payload of type Kerberos with the realm and the hosts it covers. Run on the corporate network or VPN.
Templates are YAML files under data/test-plans in the repository; the owner extends them by adding a file. Each says which releases and hardware it applies to, what success looks like and what to do when a step fails, and cites the document it follows. They are labelled as the owner's, not the publisher's.
How the areas are chosen
Each check is filed by the words in its title (then its procedure): Secure Enclave, TPM, secure boot and attestation under the hardware root of trust; Platform SSO, Entra, Kerberos and passkeys under SSO; BitLocker, FileVault and LUKS under disk encryption; passwords, smart cards, session lock and sudo under authentication; audit and logs under logging; firewall, SMB, SSH, TLS, Bluetooth and sharing under network; updates and releases under updates; enrolment and management under MDM; browsers by name; meeting rooms under collaboration. The rest is "everything else". The words are the publishers'; only the filing is this product's.
The macOS baseline · Fleet · All baselines