Security FAQ

Security FAQ

Answers to the questions security teams usually ask when approving Magic Toolbox for use. Everything here is based on how the app is built today; if something changes in a future release, this page will be updated.

Contents

• Does the app use TLS, and which version?
• How is data encrypted at rest?
• Where is the data stored?
• Are any cloud services involved that store data?
• What level of access does the app need?
• Can the app change or delete data in Jamf Pro?
• What happens to the data once a task is finished?
• Are API tokens destroyed after use?
• What does debug mode change?
• What else should a security team know?
• Recommended controls

---

Does the app use TLS, and which version?

Yes. All connections to Jamf Pro and the licence server use Apple's standard networking stack (URLSession) with App Transport Security (ATS) enabled and no exceptions configured.

• Only HTTPS is allowed. If you type an http:// address, in a tool or under Saved Servers, the app changes it to https://. Plain HTTP is never used.
• TLS 1.2 is the minimum, and TLS 1.3 is used wherever the server supports it (Jamf Cloud does).
• Certificates are validated against the macOS system trust store. There is no certificate pinning and no option to bypass validation: an invalid certificate stops the connection.

How is data encrypted at rest?

What	How it's protected
Jamf credentials: username/password or API client ID/secret	Saved only if you tick Save credentials to Keychain in a tool (off by default), or add a server under Saved Servers. A tool that uses a saved server keeps only a link to it, so each secret is stored once. Stored in the macOS Keychain as when unlocked, this device only: encrypted, unreadable while the Mac is locked, and never synced to iCloud or other devices. Deleting a saved server removes every copy of its credentials, including in Compare.
Compare credentials	Separate Keychain items, saved only if you tick Save to Keychain (off by default). Stored as when unlocked, this device only: unreadable while the Mac is locked, and never synced.
Licence key and licence token	macOS Keychain, after first unlock, this device only. The trial start date, the offline grace period's end date and the latest time the app has seen are kept there too, so they can't be changed by editing the app's preferences or setting the clock back.
Tool Lock PIN	A SHA-256 hash in the macOS Keychain. Tool Lock stops casual use; it isn't a security boundary against someone with your Mac account.
Wipe, Unused and Clone backups, and Disable undo backups	Encrypted with AES-256-GCM using a passphrase of at least 12 characters. The key is derived from the passphrase with PBKDF2-HMAC-SHA256, 600,000 iterations, to slow down guessing. GCM also detects any change to the file. Files are written readable only by your user account (0600) and read back to check them before anything is changed. Restore refuses a file whose encryption settings fall outside the expected range, and warns about backups made with an older, weaker format.
HTML reports, exported profiles and downloaded files	Written as normal files and not encrypted by the app. They rely on FileVault full-disk encryption.
Data pulled from Jamf Pro	Held in memory while the tool is using it.

Where is the data stored?

Only on the Mac running the app.

• Files you export go wherever you choose in a save or folder dialog.
• App preferences, inside the app's sandbox container, hold:
  • Saved Server names, URLs, usernames and client IDs (no secrets)
  • licence check times
  • reviewed Profile Conflicts
  • the organisation name and logo for reports
  • which tools have debug logging on
  • a bookmark to your home folder, if you grant access in Login Item Profiles
  • which tools are locked, a reference to your chosen signing certificate, and the MDM Reporting Tool's bundle ID
• Login Item Profiles rule sets: profiles.json in the app's Application Support folder, inside its sandbox container.
• Icons working folder: icons downloaded during a scan go to a temporary folder in the app's container (MagicToolbox-Icons-<id>). It's deleted when you click Scan Again, leave the tool or quit the app.
• Journals: a plain-text record of each change made by Clone, Wipe, Disable, Restore and Unused deletes. Saved next to the backup file when possible, otherwise in your Downloads folder, otherwise in the app's container.
• Debug log: memory only. See What does debug mode change?

Are any cloud services involved that store data?

No Jamf Pro data is sent to, or stored by, MDM Magic or any third-party cloud.

The app does make a few outbound connections besides your Jamf Pro servers:

Licence check

• Contacts a licence server hosted on Cloudflare Workers: magictoolboxlicenses.mdmmagic.workers.dev.
• Sends the licence key and a random ID (a UUID) the app generates on first launch and keeps in the Keychain, used to tie the licence to one Mac. No serial number or other hardware ID leaves the Mac.
• The server stores that ID and the activation date against the licence key. Deactivating clears both. It returns a signed licence token valid for 25 hours.
• It's contacted when you activate or deactivate, at app launch when a licence is saved and its token has less than 12 hours left, every 6 hours while the app is running, and when you switch back to the app (at most every 15 minutes). The free trial doesn't contact it.
• If the server can't be reached, the app keeps working until the token expires, then for a further 72 hours. After that, the token is deleted, but the licence key stays so the licence comes back when the server can be reached again.
• Deactivating only frees the key if the request comes from the Mac it's active on.
• The server rate-limits requests. Rate limiting and server errors are never treated as a rejected licence.
• The server code doesn't log licence keys or machine IDs. It logs error messages only. Cloudflare's own request logging and retention aren't set in the app or the server code, so they aren't covered here.

Downloads from links Jamf Pro provides

• Downloader: for packages, Jamf Pro returns a pre-signed download link from Jamf Cloud Distribution Service. The app downloads the package from that link, without a Jamf token. If that fails with a network error, it downloads through the Jamf Pro API instead.
• Icons and Clone: download icon images from the links in Jamf Pro. The Jamf token is only attached when the link points to your Jamf Pro server itself. Other hosts never receive it.

Network Check: when you run a scan, Network Check opens a connection to each endpoint it tests and closes it straight away. No data is sent.

Inspector: when Inspector verifies a package signature, macOS may contact Apple to check whether the certificate has been revoked.

Nothing else. There are no update checks and no analytics. Links in the About and Licence windows, and the MDM Reporting Tool tile when the app isn't set up, open in your browser only when you click them.

What level of access does the app need?

It depends on the tool. Some tools only read. Others create, update or delete objects in Jamf Pro: see Can the app change or delete data in Jamf Pro?

Tool	Access to Jamf Pro
Compare, Profile Conflicts, Smart Group Audit, Account Audit, Cert & Token Expiry, Downloader	Read only
Icons	Read. Icon upload access, plus Update Policies, only if you upload an icon or attach one to a policy
Unused	Read. Delete only if you delete items from the results (it reads each item's full record for the backup first)
Clone	Read on the source. Read, Create and Update on each destination
Restore	Create for every object type in the backup, or Update in Update existing objects mode
Disable	Read and Update
Wipe	Read and Delete
PPPC Analyser, System Extensions, Web Content Filter, Notifications, Login Item Profiles	None for analysis. Read, Create and Update macOS Configuration Profiles when you click Upload. Notifications and Login Item Profiles also read categories and computer groups when you click Scan Instance
Inspector, Network Check, Profile Signer, Profile Unsigner	None

The full list of privileges per tool is in Jamf API Permissions. An API client with a dedicated API role per job is recommended over username/password.

Permission check

• At sign-in, most tools read the account's own privileges and show which are Allowed or Denied. That needs Read API Integrations and Read API Roles (API client) or Read Accounts (username/password). Compare tests access with read requests instead.
• The check only reads. It never sends a test write or delete.
• It's a warning, not a block: you can click Proceed Anyway →. Profile uploads are the exception: they stop if Create macOS Configuration Profiles is missing.

On the Mac

• Runs as a standard user; no admin rights needed.
• Built with the App Sandbox and Hardened Runtime.
• Entitlements: outgoing network connections only (no incoming), read/write access to files and folders you pick, read/write access to the Downloads folder, and access to its own Keychain items.
• Runs one external program: /usr/bin/codesign, in Login Item Profiles, to read the Team ID of items it finds. Nothing else is launched. Profile Signer and Profile Unsigner sign and unsign files inside the app, using the macOS Security framework.
• Packages and apps are read inside the app. Package scripts are analysed as text and never run.
• No access to the camera, microphone, location, contacts, calendars, USB or Bluetooth.

Can the app change or delete data in Jamf Pro?

Yes, in the tools below, and only when you start the action.

Tool	What it changes	Safeguards
Wipe	Permanently deletes every object you select, including PreStage enrolments, API roles, API clients, Jamf Pro accounts and Jamf users. It adds items Jamf Pro requires to be deleted first, and can delete related items if you tick them.	Saves and verifies a full, passphrase-encrypted backup first unless you tick Skip backup. A Dry run shows what would happen without deleting. Deleting needs the confirmation ticked and the server's host name typed. Items that can't be restored need a separate acknowledgement. The session's own credentials are skipped unless you choose otherwise. The categories "No category assigned" and "Unknown" are never deleted. It won't delete every enabled full-access administrator account, or an account whose status couldn't be read. Every deletion is journalled. Abort Wipe asks for confirmation.
Unused	Permanently deletes the items you select in any of its 15 categories, including packages, scripts, policies, profiles, apps, groups, buildings, departments, categories and network segments. On Jamf Cloud, deleting a package also deletes its file.	Deleting is disabled for any category whose scan was incomplete. A confirmation prompt with a passphrase, and an acknowledgement of what Unused doesn't check, then a mandatory encrypted backup: nothing is deleted until you save the backup file, and items that can't be backed up aren't deleted. References are re-checked just before deleting, and anything now in use is skipped. Every deletion is journalled. Restore can re-create them from the backup.
Disable	Disables policies, Jamf Pro accounts and App Installer deployments, and removes all scope from macOS and iOS configuration profiles, restricted software, Mac App Store apps and mobile device apps. Nothing is deleted, but removing scope uninstalls profiles and apps from devices.	Nothing is selected by default. Saves and verifies an encrypted undo backup of the original state first; an item whose state can't be read isn't changed. DISABLE SELECTED stays disabled until you tick the confirmation. It won't let you disable every enabled full-access administrator account, the account you're signed in with, or an account whose status couldn't be read. Every change is journalled. Abort asks for confirmation. Undo from backup… puts everything back.
Clone	Creates objects on each destination. If an object with the same name already exists there, it's overwritten. It also creates missing categories, scripts and extension attributes, and uploads Self Service icons. New objects get no scope unless you choose to clone it; existing objects keep theirs.	A review screen and a permission check for each destination. Before anything is overwritten, Overwrite N Existing Objects? lists what would be replaced and requires a passphrase for an encrypted, verified backup of those objects. Nothing is written to any destination until you confirm. With Clone Scope, an object fails rather than being cloned with a wider scope than the source. Every change is journalled.
Restore	Creates objects from a Wipe, Unused or Clone backup, including API roles and API clients if the backup has them. In Update existing objects mode, writes backed-up objects over live ones, matched by ID and name, or by name alone.	You must tick the confirmation. Update mode also needs the server's host name typed. Abort Restore asks for confirmation. Every change is journalled.
Profile builders	Creates an unsigned, computer-level macOS configuration profile. If a profile with the same name exists, its payload is replaced. Notifications and Login Item Profiles also set the category and scope you choose (All Computers or one computer group). The other builders send no scope or category, and no builder sets a site.	Only runs when you click Upload. Stops if the Create privilege is missing. Asks before replacing a same-named profile.
Icons	Uploads icons. Attach to a Policy… reads the whole policy, changes its Self Service icon and writes the whole policy back.	Only runs when you ask it to. Shows the policy's name and asks you to confirm before attaching.

Restore only opens encrypted Wipe, Unused and Clone backups. It needs the passphrase, and it rejects a file that's been changed since Wipe wrote it. It only restores an item when the API endpoint recorded in the file is the one Magic Toolbox uses for that object type, so an edited file can't send data to a different endpoint. Anyone who knows the passphrase could still change an object's contents, so keep backups and their passphrases secure.

What happens to the data once a task is finished?

With debug logging off (the default):

• API responses are held in memory while the results are on screen, and are gone when the app quits. None are written to disk unless you export them.
• Three things are written without an export: the Icons working folder, the Login Item Profiles rule sets, and the journals written by tools that change Jamf Pro. See Where is the data stored?
• Files you save stay until someone deletes them. Wipe backups hold the full configuration of every object of the supported types, including script contents and profile payloads, encrypted with your passphrase. Unused and Clone backups hold the full records of the items deleted or overwritten, and Disable undo backups hold the original scope and enabled state, all encrypted the same way. Neither includes your Jamf credentials. If those objects contain secrets, so do the backups. Handle all exports under your organisation's data-handling policy.

Are API tokens destroyed after use?

Jamf Pro: yes.

• When a step finishes (connecting, scanning, cloning, wiping, restoring, uploading), successfully or not, the app asks Jamf Pro to revoke its token: invalidate-token for username/password sign-ins and oauth/revoke for API clients. It's best-effort: if the server can't be reached, the token expires on Jamf Pro's schedule.
• Compare also revokes its tokens when you disconnect, start a new comparison or abort a scan. Downloader revokes its token whenever it finishes a fetch or download, and when you disconnect.
• When a token expires during a task, the app signs in again for a new one.
• Tokens are held in memory only. They're never written to disk or to the debug log.

A token still in use when you quit the app isn't revoked, and stays valid until it expires on Jamf Pro's schedule.

Tokens and other hosts. Image downloads in Clone and Icons only attach the Jamf token when the link points to your Jamf Pro server. Package downloads never send a token. If Jamf Pro redirects any request to a different host, or to plain HTTP, the token is removed from the redirected request.

Licence token: a signed token, valid for 25 hours, stored in the Keychain. It's deleted when you deactivate or when the licence server rejects it.

Client secrets and passwords are never logged. If they weren't saved to the Keychain, they're gone when the app quits.

What does debug mode change?

There's one debug option, set per tool and off by default:

Option	Where	What it writes
Debug logging	Preferences › Debug Logging	Messages to the in-app log viewer. Held in memory only (the newest 5,000 entries) and cleared when the app quits. Nothing is written to disk.

The log records server host names, object names and IDs, profile identifiers and error text returned by Jamf Pro. It never records credentials or tokens. As a safeguard, anything that looks like a token, password or secret is replaced with [REDACTED] before it's stored.

What else should a security team know?

• Local-only processing. There is no vendor backend holding Jamf data.
• No telemetry. No analytics, crash reporting or third-party code: the app uses only Apple's frameworks. It doesn't include an Apple privacy manifest.
• Self-contained reports. Exported HTML reports don't load any external scripts, fonts or images, and carry a Content Security Policy that blocks them. Your report logo is embedded in the file. Values from Jamf Pro are escaped, and CSV exports neutralise values a spreadsheet would run as formulas.
• Secrets in profiles stay hidden. Profile Conflicts shows passwords, shared secrets, SCEP challenges, tokens and certificate contents as [REDACTED] in the app and its report.
• Writes can't be interrupted by accident. While a tool is changing Jamf Pro, switching tools is blocked, and closing the window or quitting asks first.
• HTTPS only. App Transport Security is on with no exceptions. See Does the app use TLS, and which version?
• Web Content Filter passwords. A server Password is hidden in the form, but saved as plain text in the .mobileconfig and in the profile uploaded to Jamf Pro.
• Licence tied to one Mac, not to hardware. The licence server holds a random ID for the Mac, not its serial number, for as long as the licence is active on it.

Recommended controls

• On self-hosted Jamf Pro, use a certificate your Macs trust and turn off TLS versions below 1.2 on the server.
• Use a dedicated, least-privilege API client for each job. See Suggested roles.
• Never give Delete privileges to a client that can reach production. Run Wipe against DEV/TEST servers only.
• Give API clients a short token lifetime, so any token that isn't revoked (for example because the app quit mid-task) expires quickly.
• Rotate client secrets on a regular schedule.
• Require FileVault on any Mac that runs the tool.
• Use a long, unique passphrase for Wipe, Unused, Clone and Disable undo backups, and store it separately from the file (for example in a password manager).
• Save backups, journals and other exports to an approved, access-controlled location, and delete them when they're no longer needed.
• Run Wipe as a dry run first.
• Use Tool Lock on shared admin Macs to keep Wipe, Disable and Clone out of casual reach.
• If you use a firewall allow-list, allow only your Jamf Pro servers, the licence server and the download hosts your Jamf Pro server uses.