Jamf Pro
Proofroom reads Jamf Pro through the Jamf Pro API with an API client (client credentials). Add it on Integrations → Catalogue → Jamf → Connect.
What each collector shows
| Collector | Kind | Default cadence | What it shows | Suggested controls |
|---|---|---|---|---|
| Device inventory with encryption | snapshot | monthly | Every managed device with its user, platform, OS version, last check-in and disk encryption (FileVault on the boot volume for Macs; data protection for iPhones and iPads). Devices not encrypted come first. | PCI DSS 12.5.1; SOC 2 CC6.1, CC6.7 |
| Operating system versions | snapshot | monthly | Each device’s OS version against your minimum for its platform, or, with no minimum, the newest version seen on that platform. Without a minimum the evidence shows drift, not patching: the headline says so and PCI DSS 6.3.3 is suggested only once you set minimums. | PCI DSS 6.3.3 (with minimums); SOC 2 CC7.1 |
| Screen lock | snapshot | quarterly | Whether each iPhone and iPad has a passcode set. Jamf Pro keeps no per-Mac screen-lock setting in its inventory, so Macs show unknown; prove the Mac lock with the configuration profile that sets it. This shows a password is set, not how soon the device locks when idle, so it is not suggested for PCI DSS 8.2.8. | SOC 2 CC6.1 |
| Devices not checking in | snapshot | monthly | Devices not seen for 30 days (or the number you set). Their encryption, updates and screen lock can no longer be confirmed. | PCI DSS 12.5.1; SOC 2 CC7.1 |
The connection also takes staleDays (30 by default) and, optionally, minimumOsVersions: one line per
platform, such as macOS 15.6, Windows 10.0.26100 or iOS 18.6. A configured minimum wins over one read from the
system. Without a minimum, a platform is compared with the newest version seen on any of its devices, which shows drift
but not whether a version is still supported.
Disk encryption is mapped to SOC 2 CC6.1 and CC6.7, not to PCI DSS 3.5.1: PCI DSS accepts disk-level encryption for stored card numbers only on removable media (3.5.1.2), so laptop encryption is not evidence for 3.5.1.
The device inventory also feeds the Endpoint coverage built-in (computers without endpoint protection, leavers’ devices), the Endpoints posture score, and a risk suggestion when devices in use are not encrypted (Admin → Risks → Raised automatically).
FileVault reads “not finished” while a Mac is still encrypting or waits for a restart. Proofroom never reads recovery keys.
Create the API client
- In Jamf Pro, go to Settings → System → API roles and clients → API Roles → New. Name it “Proofroom (read only)” and add the privileges Read Computers and, for iPhones and iPads, Read Mobile Devices. Save.
- Open API Clients → New. Name it “Proofroom”, assign the role, set Enable API client on, and save.
- Click Generate client secret and copy the Client ID and Client secret; the secret is shown once.
A role added to or removed from a client needs a new client secret before it takes effect.
Connect
| Field | Value |
|---|---|
| Jamf Pro address | Such as https://example.jamfcloud.com (an on-premises server must be reachable over https from this Proofroom server) |
| Client ID, Client secret | From step 3 |
includeMobileDevices |
On by default; needs Read Mobile Devices |
staleDays, minimumOsVersions |
See above |
Test connection gets a token and reads one computer (and one mobile device), naming the privilege to add for any that is refused.
Known limits
- Computers are read from
/api/v4/computers-inventory. A server without v4 (older Jamf Pro) answers 404 and v3 is used instead. - The token is fetched from
/api/v1/oauth/token;/api/oauth/tokenis tried if that answers 404. - UNVERIFIED: the largest page size Jamf allows is not documented; Proofroom asks for 200 at a time.