Zentral v2026.5: meet Turbo, our macOS agent

Zentral v2026.5 is out. Here is what is in it.

What’s new?

Turbo

Turbo is the Zentral agent for macOS, and this release ships the module that drives it. Unlike the munki, osquery and santa modules, this is not an integration with a third party agent: the agent and its protocol are both Zentral’s. The Turbo documentation has the full picture.

Turbo runs jobs on the machines enrolled in it — zsh scripts, and checks from the macOS Security Compliance Project (mSCP) — reports their results back to Zentral, and collects the machine inventory. Every run is published as an event, and each result feeds a compliance check status, adds or removes a machine tag, or both. Jobs are scheduled per configuration, on an interval or once inside a delivery window, and scoped with tags. The mSCP check logic and the baseline defaults are bundled and signed in the agent: a check only names a rule and the Organization Defined Value to use for it.

The agent is deployed with MDM. An enrollment is downloaded as a signed configuration profile — or as a plain plist, for a Jamf custom settings payload — and the agent exchanges its secret for a per-device token, of which Zentral only keeps the hash. Machines running Turbo skip the Munki enrollment package distributed by Monolith, since the agent reports the Munki runs itself.

Everything is manageable in the UI, over the API, and with our official Terraform provider: zentral_turbo_configuration, zentral_turbo_enrollment, zentral_turbo_script, zentral_turbo_mscp_check, zentral_turbo_recurring_job and zentral_turbo_one_time_job.

MDM secret rotation after reveal

Revealing a secret in Zentral can now schedule its rotation. The DEP enrollments already did it for the auto admin password, and two more configurations can:

• a FileVault configuration rotates the PRK and escrows it again — PRK Rotation Delay After Reveal (min), or prk_reveal_rotation_delay on zentral_mdm_filevault_config.
• a recovery password configuration rotates a dynamic password — Rotation Delay After Reveal (min), or reveal_rotation_delay on zentral_mdm_recovery_password_config. On Intel Macs the firmware password rotation checkbox applies as usual, since a reboot is needed to apply the new password.

The delay is in minutes — 5 min minimum, 1440 min (1 day) maximum, 0 disables it — long enough for whoever revealed the secret to use it first. Multiple reveals do not queue up multiple rotations. A new configuration defaults to 60 min, the configurations you already have are migrated with the rotation disabled, and Terraform defaults it to 0.

Other notable changes

The Santa rules of a sync are only recorded once the client confirms them in its postflight, and a sync the client never confirms is settled during the next preflight, with its rules sent again — the rule ledger follows what the machines actually hold. A rule download takes one request less, the new santa_postflight event reports what the client confirmed, and the preflight event carries the sync session, the rule comparison and the reason for a clean sync. The rules themselves are managed with zentral_santa_rule.

The macOS app instances carry the Apple code signing information now — team id, executable path, cdhash, entitlements and the two signing times — on the machine page, in the full JSON export and in the per-machine CSV one.

Monolith repository syncs run in the background: repositories that need more than the request timeout to sync are supported, and concurrent syncs of the same repository are prevented. The repositories are managed with zentral_monolith_repository.

We are continuing our work on the audit events: the MDM command creations, the device blocking, the artifact, blueprint artifact and enrollment changes, the push certificate, DEP token and Apps and Books location changes, and the DEP virtual server connection are all audited now, with no key material in the events. An ABM/ASM sync also posts a dep_device_change event for every device it changed, the default DEP enrollment is assigned in a chunked background task, and the DEP requests are sized from the limits the account detail advertises.

The identical records of an Osquery status log upload are collapsed into one event carrying a count, and the number of events one upload can produce is bounded.

A lot of pipeline reliability work: the raw events over 16KB are compressed with zstd, so a machine snapshot carrying a full app inventory does not take its whole batch down with it anymore, the database connections are health checked and recycled on a recoverable error, and several caches and races under threaded workers were fixed. The pages launching a background task report its outcome now, instead of reloading as if nothing had happened.

Bug fixes, upgrade

The Authorization header, the cookies and the MDM signature are not written to the JSON logs anymore: Django logs the request on every 4xx it reports, so a 401 on a public endpoint wrote the credential the client just failed to authenticate with to stdout.

Several machine snapshot commit failures are fixed, and a tree that cannot be committed because of a data error is dropped with a log line instead of crashing the preprocess worker on every redelivery. On the MDM side, the DDM declaration fetches answered with a 400 when the scope of the target changed, the DDM status report 500s on an artifact version reported under two server tokens, the app install polling that gave up after a couple of minutes, and the Apps and Books metadata looked up in the US storefront instead of the one of the location.

The Santa clean syncs are fixed: the sync type of the preflight response was sent lowercase, and the clients from 2024.6 on performed them as normal syncs. Expect the machines asking for a clean sync to rebuild their rule database after the upgrade.

Before you upgrade, read the CHANGELOG and review the backward incompatibilities carefully:

• Preprocess worker upgrade order — the raw events over 16KB are compressed now, and a preprocess worker still on the previous release drops the ones it receives. Restart the preprocess workers before the web workers.
• OIDC API token issuer CEL condition required — an issuer without a CEL condition accepted every identity token its provider signed for the configured audience, and is refused at exchange time now. Set one before you upgrade, or its clients stop getting tokens.
• Event payload datetimes and UUIDs — the {"__type__": …, "__value__": …} envelope is gone from the stores that serialize the event themselves (ClickHouse, Splunk, Panther, …). Update the queries and probes reading the two envelope subpaths.
• API endpoint PATCH — the audited API endpoints answer a PATCH with a 405. Zentral only does full updates, use PUT.
• MDM API endpoint pagination — eleven more list endpoints are paginated: ACME and SCEP issuers, FileVault and recovery password configurations, software update enforcements, OTA enrollments, blueprints, blueprint artifacts, locations, location assets and push certificates. Remember to update the official Terraform provider.
• Privilege escalation hardening — adding or changing an OIDC API token issuer or the API token of a service account requires the requester to hold every role of that account, and a PBAC policy naming a service account directly is superuser-only.
• Monolith repository sync API endpoint — it responds with a 201 and a task_id/task_result_url pair, instead of syncing the repository during the request.
• Osquery status log events — sum the new count instead of counting the events to get the number of lines the clients sent.
• MDM DEP payloads and results — the DEP token audit events lose has_expired and expires_soon (use access_token_expiry), the virtual server device sync result gains unchanged, marked_deleted and a status, and profile_assign_time stays null until a synchronization brings back the value Apple recorded.

If you run into any problem during the upgrade, contact us by email or in the #zentral macadmins Slack channel.