Kandji
In plain English
Plain definition
Kandji is an Apple-only mobile device management platform that provisions, configures and monitors macOS, iOS, iPadOS and tvOS devices via profiles, Blueprints and automated compliance checks.
Technical Definition
Kandji operates as a cloud-hosted MDM server that communicates with Apple’s Apple Push Notification service (APNs) and Apple’s Device Enrollment Program (DEP) / Automated Device Enrollment workflow. It issues configuration profiles, custom scripts and software packages to enrolled devices, and it groups these deliverables into reusable units called Blueprints, which are assigned to devices or Smart Groups based on defined criteria (such as device model, OS version or department tag). Kandji also runs recurring compliance checks against each managed device and reports pass/fail state back to administrators through its console.
Operational Relevance
Kandji is typically deployed by IT and systems teams responsible for provisioning and securing fleets of Apple hardware. Its operational value comes from reducing manual per-device configuration: instead of an administrator individually setting FileVault, firewall or Wi-Fi settings on each Mac, a single Blueprint can apply those settings consistently and reversibly across all matching devices. Compliance monitoring gives operations teams observable evidence of drift, for example a device that has disabled FileVault after enrolment.
Architecture Relationship
Kandji sits between Apple’s enrolment and push-notification infrastructure and the organisation’s identity and endpoint ecosystem. It depends on Apple Business Manager or Apple School Manager for supervised, zero-touch enrolment, and it commonly integrates with identity providers for single sign-on into the Kandji admin console and, in some configurations, into enrolled devices themselves. It does not replace an identity provider or a certificate authority; it consumes and enforces policy defined elsewhere, and it depends on Apple’s own MDM protocol and push infrastructure remaining reachable from the managed device.
Example
An operations team creates a Blueprint containing a FileVault encryption profile, a firewall configuration profile and a required software package. The Blueprint is assigned to a Smart Group matching all Macs tagged “Engineering”. When a new engineering laptop is enrolled through Automated Device Enrollment, Kandji automatically applies the Blueprint, encrypts the disk, enables the firewall and installs the required package without administrator intervention on the device itself.
Common Misunderstanding
A common misunderstanding is treating Kandji as equivalent to a general-purpose systems management tool that works across all operating systems. Kandji is Apple-only: it manages macOS, iOS, iPadOS and tvOS devices exclusively and has no agent or management path for Windows or Linux endpoints. Teams needing cross-platform management typically pair Kandji with a separate tool for non-Apple devices rather than expecting one console to cover both.
Related Terms
- Mobile Device Management (MDM)
- Apple Business Manager
- Automated Device Enrollment (formerly DEP)
- Configuration Profile
- Blueprint (Kandji-specific grouping of policies and software)
Further Reading
Administrators evaluating or operating Kandji should confirm current enrolment prerequisites, supported OS versions and Blueprint behaviour against the vendor’s own documentation before making configuration changes, since MDM platform behaviour changes with Apple platform releases.
Validating a Kandji Blueprint Change Safely
Before assigning a modified Blueprint to a production Smart Group, apply it first to a single test device or a dedicated test Smart Group in a non-production environment. Confirm the expected configuration profile, script or package installs correctly and that the device reports compliant status in the Kandji console. Keep the previous Blueprint version or its settings documented so the assignment can be reverted to the prior known-good Blueprint if the test device shows unexpected failures, such as failed profile installation or broken network connectivity. Only expand the assignment to the full production Smart Group once the test device has been observed compliant for a defined monitoring period.