Apple Device Management Guide

A device state indicating that the device has successfully completed the activation process with Apple’s servers and is ready for use.

What to Know

Activation is a prerequisite for nearly all device functionality. Until a device is activated, it cannot access cellular services, iCloud, the App Store, or most core features. Devices that fail to activate cannot be enrolled in MDM or used for productive work. Activation Lock, when enabled, requires authentication during activation to prevent unauthorized device reuse after a factory reset.

Common Scenarios

Enterprise IT: New corporate devices must activate before IT can deploy them via ADE or manual enrollment. Devices stuck in activation can indicate network issues, expired certificates, or Apple server outages. IT should verify connectivity to Apple’s activation servers (gs.apple.com, albert.apple.com) during troubleshooting.

MSP: Client devices arriving from distributors may require activation before staging. MSPs performing bulk deployments should ensure devices activate successfully before deploying configuration profiles or apps, as activation failures can block the entire provisioning workflow.

Education: Shared iPads and student devices must activate before ASM enrollment. Schools receiving large shipments should verify activation status during receiving to catch hardware or account issues early, especially when Activation Lock is managed through ASM.

In Addigy

Addigy does not directly control the activation process, but enrollment requires an activated device. If a device appears in Addigy but shows connectivity issues or incomplete enrollment, verifying activation status on the device itself (Settings > General > About) can help identify whether activation succeeded or is blocking further management.

A security state that ties a device to a specific Apple ID, preventing erasure, reactivation, or use by unauthorized parties. MDM can bypass this for supervised devices.

What to Know

Activation Lock is Apple’s anti-theft feature that makes stolen devices unusable by requiring the original owner’s Apple ID and password to reactivate after erasure. This significantly reduces the resale value of stolen devices, deterring theft. However, for corporate-owned devices, Activation Lock can create operational challenges when employees leave with Find My enabled or when devices need to be reassigned. Managed Activation Lock allows organizations to maintain theft protection while retaining the ability to bypass locks using escrowed codes.

Without proper management, Activation Lock can strand corporate devices when former employees are unreachable or uncooperative. Organizations must balance the security benefits of Activation Lock with operational needs for device lifecycle management, making supervised enrollment and bypass code escrow critical for enterprise deployments.

Common Scenarios

Enterprise IT: When an employee leaves without disabling Find My, their corporate iPhone becomes locked with their personal Apple ID. IT uses the escrowed bypass code from MDM to clear the lock and reassign the device, avoiding lengthy Apple Support processes that require proof of purchase documentation.

MSP: Clients purchasing used or refurbished devices occasionally encounter Activation Lock from previous owners. MSPs verify that all client devices are properly enrolled in MDM with bypass codes escrowed before deployment, and they educate clients on the importance of supervised enrollment for preventing device lockouts during employee transitions.

Education: Students enable Find My on school-owned iPads despite policies prohibiting it. During summer device collection, IT encounters dozens of locked devices. With Managed Activation Lock, IT clears locks automatically without tracking down each student, ensuring devices are ready for the next school year.

In Addigy

Addigy automatically escrows Activation Lock bypass codes for supervised devices enrolled via ADE. Admins can view lock status for all devices and issue the “Clear Activation Lock” command directly from the device action menu. Addigy’s device inventory shows which devices have Activation Lock enabled, helping IT proactively address potential redeployment issues before devices are collected from users.

A device state indicating the device was enrolled through Apple’s Automated Device Enrollment program, providing enhanced management capabilities and mandatory enrollment.

What to Know

The ADE-enrolled state signifies that a device is permanently bound to an organization’s MDM infrastructure through Apple Business Manager or Apple School Manager. This enrollment cannot be removed by users without administrator approval, ensuring continuous management even if the device is erased or reset. ADE-enrolled devices are automatically supervised, unlocking advanced management features like single app mode, AirPlay restrictions, and granular control over system features. This persistent management is essential for maintaining security and compliance across corporate-owned devices.

Organizations can immediately identify ADE-enrolled devices in their inventory and apply appropriate policies based on this trusted enrollment state. The ADE-enrolled designation guarantees the device went through proper organizational onboarding rather than manual user enrollment, providing audit trail and compliance documentation for device provenance and ownership verification.

Common Scenarios

Enterprise IT: IT maintains an inventory of all ADE-enrolled devices, distinguishing them from manually enrolled or BYOD devices. Corporate security policies requiring supervised management are only deployed to ADE-enrolled devices. When devices are reported lost, IT verifies ADE enrollment status to confirm the device will automatically re-enroll if someone attempts to erase and reactivate it, preventing unauthorized use.

MSP: MSPs track which client devices are ADE-enrolled versus manually enrolled, using this state to determine appropriate management strategies. ADE-enrolled devices receive aggressive management policies and security configurations, while manually enrolled devices receive lighter-touch policies. During client offboarding, the MSP releases ADE-enrolled devices from Apple Business Manager to transfer ownership.

Education: Schools identify ADE-enrolled iPads for use in standardized testing or assessments requiring single app mode and strict restrictions. Only ADE-enrolled devices are configured for shared iPad scenarios where multiple students use the same device. The ADE-enrolled state ensures devices remain under school management even if students reset them at home.

In Addigy

Addigy clearly displays ADE enrollment status in device details and inventory views, allowing you to filter and report on ADE-enrolled devices separately from manually enrolled ones. Smart groups can automatically assign policies based on ADE enrollment state, ensuring only properly enrolled devices receive supervised-only restrictions. Addigy’s enrollment dashboard tracks ADE enrollment success rates, showing which assigned devices have completed enrollment and which are pending.

When viewing a device in Addigy, the enrollment method is prominently displayed, indicating whether it came through ADE or manual enrollment. This helps admins quickly understand what management capabilities are available for each device and troubleshoot enrollment issues by verifying expected enrollment state matches actual state.

Extends end-to-end encryption to most iCloud data categories (Backups, Photos, Notes). Keys are stored only on trusted devices, meaning Apple cannot access the data.

What to Know

Advanced Data Protection addresses the highest tier of data security and privacy requirements by ensuring that even Apple cannot decrypt user data stored in iCloud. This is critical for organizations handling sensitive information, meeting regulatory compliance demands (GDPR, HIPAA-adjacent contexts), or operating in industries where data sovereignty and zero-trust architectures are mandated. However, it introduces operational complexity: if a user loses access to all trusted devices, data recovery becomes impossible, placing greater responsibility on IT to manage device trust and user education.

For corporate deployments, ADP can conflict with certain MDM and backup strategies that assume Apple’s ability to assist with account recovery. Organizations must carefully evaluate whether their security posture requires this level of protection or if standard iCloud encryption suffices.

Common Scenarios

Enterprise IT: Legal, healthcare, or financial organizations may require ADP to satisfy data protection audits and ensure client confidentiality. IT must establish clear policies around device loss and recovery key management, as losing access to all trusted devices results in permanent data loss.

MSP: Recommending ADP to clients requires careful consultation. While it enhances security, MSPs must educate clients on the risks of account lockout and ensure users understand the recovery implications. For clients with high turnover or less technical users, standard encryption may be a safer recommendation.

Education: ADP is generally not recommended for student accounts due to the risk of permanent data loss if a student forgets their credentials and loses their device. Schools prioritize accessibility and data recovery over maximum encryption, making standard iCloud protection more practical for educational environments.

In Addigy

Addigy does not directly manage ADP settings, as this is a user-level iCloud configuration controlled through Apple ID settings. However, admins can deploy scripts or configuration guidance to educate users on enabling ADP. Addigy’s reporting can help track device trust status and identify users who may be at risk of account lockout, though ADP enforcement remains outside the scope of traditional MDM controls.

APNs is Apple’s cloud-based service that enables third-party applications and MDM solutions to send push notifications to managed Apple devices.

What to Know

APNs is the foundational communication layer for all Apple MDM and DDM operations. Without functioning APNs connectivity, MDM servers cannot trigger devices to check in, making real-time management impossible. Commands would be delayed until devices check in on their own schedule, which could be hours or days. APNs reliability directly affects IT’s ability to respond to security incidents, deploy urgent updates, or troubleshoot user issues. An expired APNs certificate – also known as a Push Certificate — renders the entire MDM infrastructure non-functional until renewed.

Organizations must ensure continuous APNs connectivity by maintaining a valid Push Certificates, allowing Apple’s APNs gateway addresses in firewalls, and monitoring certificate expiration dates. Certificate renewal must occur before expiration, as there is no grace period. Loss of APNs connectivity during a security incident could prevent IT from remotely locking or wiping compromised devices.

Common Scenarios

Enterprise IT: IT teams must track APNs certificate expiration dates and renew certificates annually before they expire. Push notification failures often indicate firewall issues blocking ports 443 or 2197, or corporate proxies interfering with persistent TLS connections. During security incidents, APNs enables immediate remote lock or wipe commands.

MSP: MSPs managing multiple client MDM instances must track certificate expiration across all clients and establish renewal workflows 30-60 days before expiration. Importantly, Push Certificates should be created by the MSPs client using an Apple ID they manage.

Client network changes (new firewalls, proxy servers) can silently break APNs connectivity, causing delayed command delivery. MSPs should monitor APNs health proactively to catch issues before clients report problems.

Education: School districts rely on APNs for daily device management operations during the school year. Summer breaks provide natural windows for certificate renewal and APNs infrastructure maintenance. Education networks with strict content filtering must ensure APNs gateways remain accessible even when other Apple services are restricted.

In Addigy

Addigy provides Push Certificate management, including in-app alerts for upcoming certificate expiration and step-by-step renewal guidance. Apple sends email notifications about expiring certificates directly to the Apple ID associated with the certificate. Addigy displays APNs connectivity status for enrolled devices and shows in-app alerts when devices fail to respond to push notifications. Certificate renewal is a straightforward process accessed through the Addigy admin portal, with detailed documentation available in the support center.

When troubleshooting device check-in issues, Addigy’s live device info and monitoring shows APNs activity and can help identify patterns indicating network-level APNs blocking. Addigy also provides diagnostic tools to verify APNs connectivity from the Addigy infrastructure to Apple’s servers and from client networks to Addigy and Apple endpoints.

Process of remotely configuring app settings through MDM via Managed App Configuration dictionaries. Allows pre-configuring server URLs, user settings, etc.

What to Know

App Configuration eliminates the need for end users to manually configure enterprise apps with corporate settings, server endpoints, authentication parameters, or feature toggles. This dramatically reduces help desk tickets, onboarding time, and user error while ensuring every device is consistently configured according to organizational policy. Without it, admins must either rely on users to correctly enter complex settings or manually configure every device in person.

For security-conscious organizations, App Configuration also prevents sensitive configuration data from being exposed through other distribution channels. Settings are delivered directly from the MDM server to the app’s secure container, ensuring credentials, API keys, or internal server URLs never pass through email, wikis, or chat systems where they might be intercepted or leaked.

Common Scenarios

Enterprise IT: Pre-configure VPN clients with server addresses and authentication methods, set default Microsoft 365 tenants, configure email clients with Exchange autodiscover URLs, or customize productivity apps with internal SharePoint/OneDrive paths without requiring users to know or enter these details.

MSP: Deploy standardized configurations across multiple client organizations by maintaining separate configuration dictionaries per client. Common use cases include remote monitoring tools (RMM agents), communication apps (Slack/Teams channels), and documentation systems (ConnectWise URLs) that vary per client but must be consistently configured across each client’s fleet.

Education: Automatically configure classroom apps like Google Classroom, Canvas, or Schoology with district-specific settings. Lock down testing apps with exam-specific parameters or configure content filtering apps with age-appropriate restrictions without requiring teacher or student intervention.

In Addigy

Addigy supports Managed App Configuration through its Apple Apps (formerly VPP) interface and Custom Profile deployment. Admins can deploy app configurations either by selecting a VPP-managed app and filling out the configuration schema provided by the app developer, or by manually crafting a configuration dictionary in a Custom MDM Profile for apps that support it. Addigy automatically delivers configuration changes to devices whenever the policy is updated, ensuring configurations remain current without requiring app reinstallation.

Apple Business Manager is the central hub for enterprise Apple device management. It allows organizations to automatically enroll devices in MDM via Automated Device Enrollment, purchase apps and books in volume, and create Managed Apple IDs for employees.

What to Know

Apple Business Manager is the foundational platform for zero-touch deployment and streamlined device lifecycle management. Without ABM, organizations lose the ability to automatically supervise devices, enforce MDM enrollment at setup, and centrally manage app licenses. ABM integration with an MDM like Addigy transforms manual enrollment workflows into automated, scalable deployments that prevent users from bypassing management controls.

ABM also provides financial accountability by consolidating all Apple purchases under a single organization account, enabling volume discounts and simplified billing. For regulated industries, ABM is essential for maintaining an auditable chain of custody and ensuring devices remain under organizational control from factory shipment through decommissioning.

Common Scenarios

Enterprise IT: Corporate IT uses ABM to assign newly purchased devices to the MDM before they ship, ensuring zero-touch enrollment when employees first power them on. IT can push VPP apps and books to managed devices silently, eliminating manual App Store logins. ABM also allows IT to create Managed Apple IDs for employees who need iCloud collaboration features while maintaining corporate control over data.

MSP: MSPs managing multiple clients should create a separate ABM instance for each client organization to maintain proper license segregation and billing boundaries. Some MSPs use their own ABM for small clients without dedicated IT staff, though this creates shared licensing pools that require careful tracking. ABM integration is a key onboarding step for any new client with Apple devices.

Education: Schools use Apple School Manager (ASM), the education-specific equivalent of ABM, to manage student devices and deploy classroom apps. ASM includes additional features like Shared iPad support and integration with Student Information Systems for automatic roster syncing. ASM is required for education-specific features like Managed Apple IDs for students under 13.

In Addigy

Addigy integrates directly with Apple Business Manager to enable Automated Device Enrollment and VPP app distribution. During initial setup, admins upload Addigy’s MDM server token to ABM and assign devices to the Addigy MDM server. Once connected, devices purchased through ABM-enrolled resellers automatically appear in Addigy’s device list and enroll when powered on. Addigy syncs VPP app licenses from ABM, allowing admins to deploy apps to devices without requiring user Apple IDs.

Addigy’s ABM integration supports multiple ABM instances, allowing MSPs to manage separate client accounts from a single Addigy tenant. Addigy displays each device’s ABM assignment status and provides alerts when MDM server tokens need renewal, preventing enrollment disruptions.

A macOS application that allows admins to configure and deploy multiple iOS, iPadOS, and tvOS devices simultaneously. It allows for creating configuration profiles, installing apps, updating operating systems, and preparing devices for deployment, including manual supervision.

What to Know

Apple Configurator is the primary tool for manually supervising iOS and iPads when Automated Device Enrollment is not available. Supervision unlocks critical management capabilities, and Configurator is often the only practical way to supervise legacy devices or devices purchased from non-ABM-enrolled resellers. For small deployments or one-off device setups, Configurator provides a faster alternative to full MDM enrollment workflows.

Configurator also enables bulk device preparation, allowing IT to configure dozens of devices simultaneously with identical settings, apps, and profiles. This is essential for education deployments where IT needs to prepare classroom carts of iPads before the school year, or for retail environments preparing point-of-sale devices.

Common Scenarios

Enterprise IT: IT uses Configurator to manually supervise existing unsupervised corporate devices without erasing and re-enrolling through ADE. This is common when retrofitting older devices or devices purchased before the organization adopted ABM. Configurator is also used to restore devices to known-good configurations when troubleshooting, or to prepare demo devices for trade shows and presentations.

MSP: MSPs use Configurator for clients with small Apple deployments who don’t justify the overhead of ABM setup. It’s also used for emergency device provisioning when a client needs devices deployed immediately without waiting for ABM device assignment. MSPs should document Configurator workflows carefully since manual supervision requires physical device access and can’t be done remotely.

Education: Schools use Configurator to prepare shared iPad carts, installing baseline apps and profiles before distributing devices to classrooms. Configurator’s ability to simultaneously prepare 30+ devices makes it ideal for summer deployment cycles. Schools also use it to create blueprints—reusable device configurations that can be applied to new devices each year.

In Addigy

While Addigy primarily manages devices enrolled through ADE, it fully supports devices supervised via Apple Configurator. Devices supervised with Configurator and then enrolled in Addigy gain access to the same supervision-only features as ADE devices. Addigy can identify whether a device was supervised via ADE or Configurator in the device details page, helping admins understand each device’s enrollment history.

Addigy documentation provides step-by-step Configurator workflows for scenarios where ADE isn’t available. Admins can export Addigy enrollment profiles for use in Configurator, streamlining the process of preparing devices for Addigy management.

Apple Configurator’s specialized recovery features for iOS and iPads that cannot be restored through standard iTunes/Finder restore methods. It can revive devices stuck in recovery mode or restore devices that won’t boot.

What to Know

Apple Configurator Recovery provides a critical last-resort option for recovering devices that are completely unresponsive or stuck in boot loops that Finder cannot resolve. When standard restore methods fail due to corrupted firmware or severe software issues, Apple Configurator’s deeper system access can often revive or restore the device without requiring depot service. This capability is essential for minimizing device downtime and avoiding costly hardware replacements for software-related failures.

Common Scenarios

Enterprise IT: IT teams use Apple Configurator Recovery to handle failed iOS updates that left devices in recovery mode, corrupted MDM profiles preventing boot, or devices returned from users in an unknown state. Having this tool available in-house reduces dependency on Apple Store Genius Bar appointments and keeps critical devices operational.

MSP: MSPs supporting clients with large iPad or iPhone deployments keep Apple Configurator on hand to quickly recover devices that fail during mass updates or MDM enrollment. This prevents expensive device swaps and maintains service level agreements when standard restore methods fail.

Education: School IT staff use Apple Configurator Recovery to restore student iPads that won’t boot after students attempt jailbreaks, install beta profiles, or the device experiences update failures. The tool enables rapid turnaround without sending devices out for repair, keeping devices available for classroom use.

In Addigy

While Apple Configurator Recovery operates outside of Addigy’s MDM capabilities, Addigy’s Return to Service feature complements this workflow by automating the post-recovery re-enrollment and configuration process. After using Apple Configurator to revive a device, connecting it to Addigy via Return to Service ensures the device is immediately re-enrolled, supervised, and configured according to organizational policies without manual intervention.

A built-in hardware diagnostic tool that runs outside of macOS to test Mac components for hardware failures.

What to Know

Apple Diagnostics provides definitive hardware test results that determine whether a Mac issue stems from faulty hardware or software configuration problems. This distinction is critical for warranty claims, AppleCare service authorization, and avoiding unnecessary software troubleshooting when hardware replacement is required. The tool generates reference codes that Apple Support and Genius Bar staff use to identify specific component failures, streamlining repair processes and ensuring appropriate service coverage.

Common Scenarios

Enterprise IT: IT departments run Apple Diagnostics on Macs exhibiting intermittent crashes, display issues, or performance problems to determine if the device needs hardware service or software remediation. The diagnostic reference codes provide clear documentation for warranty claims and justify device replacement requests to procurement teams.

MSP: MSPs use Apple Diagnostics to quickly triage client-reported Mac issues and determine whether to attempt remote software fixes or schedule on-site hardware service. This prevents wasted billable hours troubleshooting software when a hardware fault is the root cause, and provides clients with concrete evidence supporting hardware replacement recommendations.

Education: School IT staff run Apple Diagnostics on student or staff Macs before sending devices for repair to verify hardware faults and obtain reference codes required for AppleCare service claims. This ensures devices aren’t sent for repair unnecessarily and provides documentation for tracking hardware failure rates across the fleet.

In Addigy

While Apple Diagnostics runs independently of MDM, Addigy’s remote management capabilities allow IT to guide end users through the diagnostic process via Remote Desktop or by deploying instructions through notifications. Addigy’s device inventory also tracks hardware serial numbers and warranty status, helping admins correlate diagnostic results with AppleCare eligibility before initiating service requests.

A unique account used to access Apple services including iCloud, App Store, Apple Music, and others. In MDM environments, personal Apple IDs present challenges as organizations cannot control data stored in personal iCloud accounts.

What to Know

Personal Apple IDs create data governance and security risks on corporate devices because organizations have no visibility into or control over content synced to personal iCloud accounts. Corporate documents stored in a personal iCloud Drive, passwords saved to personal iCloud Keychain, or photos backed up to personal iCloud Photo Library all exist outside the organization’s security perimeter. If an employee leaves, the organization cannot reclaim data stored under their personal Apple ID.

Apple ID restrictions are among the most common MDM policies deployed on supervised corporate devices. Blocking iCloud sign-in, disabling iCloud Backup, or requiring Managed Apple IDs instead of personal ones are critical for maintaining data control and compliance with regulations like GDPR, HIPAA, or SOX.

Common Scenarios

Enterprise IT: Corporate IT typically blocks personal Apple ID use on company-owned devices to prevent corporate data from being synced to personal iCloud accounts. For employees who need iCloud features like Keychain or collaboration tools, IT provides Managed Apple IDs that remain under organizational control. On BYOD devices, IT may allow personal Apple IDs but deploy app-level restrictions to segment corporate and personal data.

MSP: MSPs should establish clear policies with clients about personal Apple ID use. Some clients allow personal IDs on BYOD devices, while others require Managed Apple IDs across the board. MSPs often see issues during offboarding when ex-employees’ personal Apple IDs retain access to corporate data synced before restrictions were applied.

Education: Schools prohibit personal Apple IDs on student devices to prevent students from accessing age-inappropriate content, bypassing content filters, or syncing school-owned files to personal accounts. Students receive Managed Apple IDs created through Apple School Manager, which provide iCloud access while maintaining school oversight.

In Addigy

Addigy provides comprehensive Apple ID restrictions in its Restrictions payload, allowing admins to block iCloud sign-in entirely, disable specific iCloud services (Drive, Photos, Backup, Keychain), or prevent account modification. These restrictions require supervised devices and are enforced immediately upon profile deployment. Addigy also reports which devices have Apple IDs signed in, helping admins identify non-compliant devices.

Apple’s subscription-based music streaming service. In MDM environments, admins can restrict or allow Apple Music through configuration profiles to prevent bandwidth usage or enforce productivity policies.

What to Know

Apple Music restrictions are commonly deployed to preserve network bandwidth and enforce workplace productivity standards. Streaming music can consume significant bandwidth on cellular-connected devices, driving up data costs for organizations with pooled cellular plans. Beyond bandwidth concerns, some organizations restrict entertainment services on business-purpose devices to reinforce acceptable use policies and minimize workplace distractions.

Common Scenarios

Enterprise IT: Corporate IT often blocks Apple Music on shared devices like conference room iPads, kiosk devices, or corporate-owned iPhones where music streaming serves no business purpose. On employee-assigned devices, policies vary—some organizations allow music during work hours for employee satisfaction, while others restrict it to maintain productivity standards.

MSP: MSPs configure Apple Music restrictions based on client industry and culture. Law firms and financial services clients commonly block streaming services entirely, while creative agencies or tech startups may leave them enabled. MSPs should document each client’s preference and apply restrictions consistently across the fleet.

Education: Schools typically restrict Apple Music on student devices to preserve classroom focus and prevent students from streaming content during instructional time. Teachers may be allowed access on their devices. Some schools restrict music streaming only during school hours using time-based restrictions.

In Addigy

Addigy’s Restrictions payload includes an “Allow Music Service” option that disables Apple Music entirely when unchecked. This restriction applies system-wide and prevents the Music app from streaming Apple Music content, though locally stored music remains accessible. The restriction requires a supervised device on iOS/iPadOS and takes effect immediately when the profile is deployed.

Apple’s mobile payment and digital wallet service. In MDM environments, Apple Pay can be restricted or allowed through configuration profiles to prevent unauthorized purchases or enforce payment policies.

What to Know

Apple Pay restrictions prevent users from adding personal payment methods to corporate devices, which is critical for preventing unauthorized purchases and maintaining clear boundaries between corporate and personal use. Organizations issuing devices to field workers, retail employees, or delivery drivers often restrict Apple Pay to prevent devices from being used for personal transactions, which could create liability issues or complicate expense reporting.

Common Scenarios

Enterprise IT: Corporate IT restricts Apple Pay on shared devices like retail point-of-sale iPads, showroom demo devices, or field service iPhones to prevent personal purchases. For employee-assigned devices, policies vary based on the organization’s BYOD stance—some allow Apple Pay for employee convenience, while others block it to maintain strict corporate-only usage.

MSP: MSPs typically restrict Apple Pay on client devices by default unless the client explicitly requests otherwise. This prevents accidental personal charges and eliminates confusion about which devices are approved for personal payment methods. MSPs should clarify Apple Pay policies during client onboarding to avoid misunderstandings.

Education: Schools universally restrict Apple Pay on student devices to prevent unauthorized purchases and eliminate the risk of students using school-issued devices for personal transactions. Teacher devices may have Apple Pay enabled for personal use if the school allows personal use of teacher-assigned devices.

In Addigy

Addigy’s Restrictions payload includes an “Allow Apple Pay” toggle that disables Apple Pay when unchecked. This restriction prevents users from adding cards to Wallet, making payments with existing cards, or using Apple Pay on the web. The restriction applies on supervised iPhones and iPads and takes effect immediately upon profile deployment. Addigy’s interface clearly labels this as a supervised-only restriction to prevent admins from deploying unsupported policies.

A web-based portal for educational institutions to deploy devices, manage Managed Apple IDs for students/staff, and purchase content. Supports features like Shared iPad and Classroom app integration.

What to Know

Apple School Manager is the foundational platform for K-12 device deployments, providing zero-touch enrollment, student account management, and classroom-specific features unavailable in Apple Business Manager. ASM enables Shared iPad, which allows multiple students to use a single device while maintaining personalized experiences, and integrates with Student Information Systems to automatically provision and deprovision student accounts based on enrollment data.

ASM is also the only authorized way to create Managed Apple IDs for students under 13, complying with COPPA regulations while providing students access to iCloud, collaboration tools, and educational apps. Without ASM, schools cannot deploy supervised iPads at scale or provide students with secure, institutional Apple IDs.

Common Scenarios

Enterprise IT: While ASM is designed for education, some corporate training programs use it for apprenticeship or certification programs that involve student-like cohorts. However, most businesses use Apple Business Manager instead, as ASM’s education-specific features are unnecessary outside of academic environments.

MSP: MSPs serving K-12 clients should be familiar with ASM setup and management, as it differs meaningfully from ABM. MSPs need to understand Shared iPad configuration, Classroom app deployment, and student roster syncing from SIS platforms like PowerSchool or Infinite Campus. Unlike ABM, ASM includes education-specific roles like Site Manager and Instructor, which MSPs must configure properly.

Education: Schools use ASM to assign newly purchased iPads to their MDM, create Managed Apple IDs for students and teachers, and purchase educational apps and books through VPP. ASM’s SIS integration automates student account creation and class roster assignment, eliminating manual account management. Schools also use ASM to configure Shared iPad for classroom cart deployments and enable Classroom app for teacher-led instruction.

In Addigy

Addigy integrates with Apple School Manager using the same MDM server token workflow as Apple Business Manager. Schools upload Addigy’s token to ASM, assign devices to Addigy, and configure enrollment settings. Addigy supports all ASM-specific features including Shared iPad deployment, Classroom app management, and Managed Apple ID assignment. Addigy displays student roster data synced from ASM and allows admins to scope policies to specific classes or grade levels.

Apple’s subscription-based video streaming service. Administrators can restrict access to Apple TV+ through configuration profiles, particularly on business-purpose devices.

What to Know

Apple TV+ restrictions are deployed to enforce acceptable use policies and preserve network bandwidth. Video streaming consumes substantially more data than most other services, making it a primary target for restriction on metered cellular connections or bandwidth-constrained networks. Beyond bandwidth, restricting entertainment services on corporate devices reinforces the expectation that devices are for business use, reducing workplace distractions.

Common Scenarios

Enterprise IT: Corporate IT restricts Apple TV+ on shared devices like conference room Apple TVs or lobby kiosks to prevent personal use. On employee-assigned devices, policies vary based on organizational culture—some allow streaming for downtime use, while others maintain strict business-only policies. IT often restricts all streaming services (Apple TV+, Netflix, YouTube) as a bundle rather than targeting individual services.

MSP: MSPs configure streaming restrictions based on client preferences and bandwidth constraints. Clients with limited internet capacity or strict acceptable use policies typically request blanket streaming restrictions. MSPs should apply these restrictions at the profile level to ensure consistency and prevent users from re-enabling services after deployment.

Education: Schools restrict Apple TV+ on student devices to maintain classroom focus and prevent students from streaming content during instructional time. Some schools allow streaming on student devices only outside school hours using time-based restrictions, while others block it entirely to preserve bandwidth for educational applications.

In Addigy

Addigy does not currently offer a dedicated restriction specifically for Apple TV+, but admins can achieve similar results by restricting the App Store to prevent installation of the Apple TV app, or by using content filtering profiles to block access to Apple TV+ streaming domains. For iPhones and iPads, Addigy’s “Allow Video Conferencing” restriction, when disabled, can limit video streaming capabilities more broadly.

A streamlined enrollment process that automatically enrolls devices in MDM during initial setup without requiring manual configuration. Enables zero-touch deployment and mandatory supervision.

What to Know

Automated Device Enrollment (ADE) is the foundation of modern Apple device management, eliminating manual enrollment steps and ensuring devices are managed from the moment they’re powered on. ADE-enrolled devices automatically connect to your MDM server during Setup Assistant, cannot skip enrollment, and are placed under supervision—unlocking advanced management features unavailable to manually enrolled devices. This mandatory enrollment prevents users from bypassing management, critical for maintaining security and compliance in corporate environments.

For organizations managing dozens or thousands of devices, ADE dramatically reduces deployment time and IT overhead. Devices can be shipped directly to end users and automatically configure themselves without IT touching them. ADE also provides persistent enrollment: even if a device is erased or wiped, it will re-enroll automatically upon reactivation, ensuring devices never leave management.

Common Scenarios

Enterprise IT: Large corporations use ADE to deploy hundreds of devices to remote employees. Devices ship directly from Apple or resellers, arrive pre-configured with corporate settings, and users complete setup themselves. IT configures pre-stage enrollment profiles to skip Setup Assistant screens, pre-install apps, and enforce security policies before the user even sees the desktop.

MSP: Managed service providers leverage ADE to streamline client onboarding. When acquiring devices for a client, MSPs add serial numbers to Apple Business Manager under the client’s MDM instance, ensuring every device enrolls automatically. This eliminates the need for MSP technicians to manually touch devices before deployment, reducing labor costs and accelerating delivery timelines.

Education: Schools use ADE to prepare shared iPad carts and 1:1 student device programs. Devices purchased through Apple School Manager automatically enroll, allowing IT to configure device restrictions, install educational apps, and enable Shared iPad mode before students receive them. ADE ensures devices remain managed even if students attempt to erase them.

In Addigy

Addigy integrates with Apple Business Manager and Apple School Manager to enable Automated Device Enrollment. After connecting your ABM/ASM account to Addigy, you configure pre-stage enrollment profiles that define which Setup Assistant screens to skip, whether to require authentication, and which policies to apply immediately. When a device with a serial number assigned to Addigy powers on, it automatically downloads its enrollment profile during Setup Assistant, enrolls into Addigy, and applies the assigned policies and apps without user intervention.

Addigy’s ADE workflow allows you to create multiple pre-stage profiles for different device types or departments, assign devices to specific policies during enrollment, and track enrollment status in real time. You can also configure account-driven enrollment to tie devices to specific users in your directory, ensuring personalized configurations deploy automatically based on user identity.

An external drive containing a complete macOS installer that can boot a Mac and install or reinstall macOS without requiring network access.

What to Know

Bootable installers provide offline macOS installation capability when Internet Recovery is unavailable due to network issues, firewall restrictions, or extremely slow connections. They also enable downgrading to specific macOS versions when troubleshooting compatibility issues with applications or hardware, a task that Internet Recovery cannot perform since it installs the latest compatible OS. For organizations managing fleets, having bootable installers for multiple macOS versions ensures rapid recovery without dependency on Apple’s servers or local network infrastructure.

Common Scenarios

Enterprise IT: IT teams maintain bootable installers for approved macOS versions to ensure consistent deployment and avoid forced upgrades when using Internet Recovery. This is especially important in regulated environments where specific OS versions must remain in use until software compatibility is validated.

MSP: MSPs keep bootable installers on hand when servicing client sites with poor internet connectivity or restrictive firewalls that block Apple’s recovery servers. Having multiple macOS versions available enables quick downgrade scenarios when clients experience compatibility issues after automatic updates.

Education: School IT departments create bootable installers at the beginning of each school year to rapidly reimage lab Macs during breaks without overwhelming the network or relying on internet access. This ensures predictable imaging times and consistent OS versions across all classroom devices.

In Addigy

While Addigy does not directly create bootable installers, admins can use Addigy to deploy scripts that download and create bootable installers on user devices, or deploy documentation instructing users how to create them. After using a bootable installer to restore a Mac, devices can be re-enrolled in Addigy through ADE or manual enrollment to restore management and policy configurations.

A device ownership model where employees use personally-owned devices for work purposes, typically with limited MDM management capabilities.

What to Know

BYOD (Bring Your Own Device) represents a fundamental shift in enterprise device strategy, allowing employees to use personal smartphones, tablets, and computers for work. This model reduces organizational hardware costs, increases employee satisfaction by letting people use familiar devices, and supports flexible work arrangements. However, BYOD introduces significant management and security challenges—organizations must protect corporate data without invasively controlling personal devices, balance employee privacy rights with compliance requirements, and secure company information on devices they don’t own or fully control.

BYOD requires different enrollment and management approaches than corporate-owned devices. Manual enrollment and User Enrollment are the primary methods for BYOD, as they respect device ownership boundaries and limit MDM’s access to personal information. Organizations must establish clear BYOD policies defining acceptable use, security requirements, data separation, and what happens when employees leave. Legal considerations around privacy, data wiping rights, and liability for lost or stolen devices make BYOD governance as important as technical implementation.

Common Scenarios

Enterprise IT: Employees use personal iPhones for corporate email and Slack through User Enrollment, which separates work apps and data from personal content. IT enforces passcode requirements and encryption on managed apps while having zero visibility into personal apps, photos, or messages. When employees leave, IT remotely removes the managed partition, wiping corporate data while preserving personal content. Clear BYOD agreements define acceptable use and employees’ obligation to maintain security updates.

MSP: Small business clients adopt BYOD to reduce IT costs. The MSP implements BYOD using manual enrollment with lightweight policies—email profiles, VPN access, and minimum security requirements like passcodes and OS updates. The MSP creates client-specific BYOD policies balancing security needs with privacy expectations, and provides enrollment documentation for new hires. Device ownership is tracked separately from corporate-owned assets for inventory and compliance.

Education: Universities support BYOD for students accessing institutional resources. Students enroll personal devices via User Enrollment to receive campus Wi-Fi certificates, access learning management systems, and install required educational apps. The university enforces minimal restrictions—only on managed apps—while respecting student privacy. Clear policies inform students that institutional access requires enrollment and defines what data the university can access versus what remains private.

In Addigy

Addigy supports BYOD through User Enrollment and manual enrollment methods. For iOS/iPadOS BYOD, Addigy’s User Enrollment integration creates separate managed partitions, ensuring complete separation between corporate and personal data. For macOS BYOD, manual enrollment provides management with clear unsupervised designations, and Addigy automatically limits available management features to respect personal device ownership.

Addigy’s BYOD capabilities include managed app deployment to personal devices, VPN and Wi-Fi profile distribution, and certificate management for institutional access—all while maintaining privacy boundaries. You can create BYOD-specific policies that enforce minimum security requirements without invasive monitoring, and Addigy’s inventory clearly distinguishes BYOD devices from corporate-owned assets. Remote wipe capabilities on BYOD devices are limited to managed content only, preventing accidental deletion of personal data.

The process of deploying and maintaining digital certificates for authentication and encryption. MDM leverages SCEP and configuration profiles for scale.

What to Know

Certificate management is foundational to enterprise network security, enabling passwordless authentication to Wi-Fi, VPN, email servers, and internal applications. Without proper certificate deployment, organizations must rely on static passwords or less secure authentication methods, increasing the risk of credential theft and unauthorized access. MDM-driven certificate management using SCEP (Simple Certificate Enrollment Protocol) automates issuance, renewal, and revocation at scale, ensuring devices maintain valid credentials without manual user intervention.

Poor certificate hygiene leads to service outages when certificates expire, security vulnerabilities when revoked certificates aren’t removed, and user frustration when authentication fails unexpectedly. Proper certificate lifecycle management through MDM is essential for maintaining both security posture and operational continuity.

Common Scenarios

Enterprise IT: Corporate Wi-Fi networks use 802.1X certificate-based authentication to ensure only authorized devices can connect. IT deploys device certificates via SCEP through MDM, eliminating the need for shared Wi-Fi passwords and enabling automatic re-enrollment when certificates near expiration. This is also used for VPN access, internal web portals, and email signing.

MSP: MSPs configure certificate-based authentication for clients to reduce password sprawl and improve security compliance. They integrate SCEP with client certificate authorities to automate certificate deployment across managed devices, reducing support tickets related to Wi-Fi or VPN authentication failures.

Education: Schools deploy certificates to student devices for secure access to campus Wi-Fi and filtering proxies. Certificate-based authentication prevents students from sharing network credentials and allows IT to revoke access immediately when a device is reassigned or a student graduates.

In Addigy

Addigy supports certificate deployment through both manual certificate profiles (for static certificates) and SCEP payloads (for dynamic certificate issuance). Admins can configure SCEP profiles to integrate with external certificate authorities, automatically issuing unique device certificates during enrollment. Addigy’s certificate inventory provides visibility into installed certificates, expiration dates, and validation status, helping admins proactively rotate certificates before expiration causes service disruption.

Certificate pinning is a security technique that validates SSL/TLS certificates against a pre-defined set of trusted certificates or public keys, rather than relying solely on the system’s certificate authority trust store.

What to Know

Certificate pinning defends against man-in-the-middle attacks where attackers present fraudulent certificates signed by compromised or rogue certificate authorities. In high-security environments, the standard CA trust model is insufficient because any CA in the system trust store can issue certificates for any domain. Certificate pinning narrows the trust boundary to specific, known certificates, preventing attackers from impersonating servers even with valid certificates. This is particularly critical for MDM communications, which handle sensitive device management commands and corporate data.

When implemented correctly, certificate pinning adds a significant layer of protection against sophisticated attacks. However, it requires careful certificate lifecycle management — pinned certificates that expire or rotate require profile updates, and incorrect pinning configurations can break connectivity entirely. Organizations must balance security benefits against operational complexity.

Common Scenarios

Enterprise IT: High-security enterprises in finance, healthcare, or government often require certificate pinning for MDM connections to protect against nation-state attacks or advanced persistent threats. IT must coordinate certificate rotations with MDM profile updates to avoid service disruptions. Certificate pinning is most commonly implemented for corporate apps and VPN configurations rather than the MDM enrollment profile itself.

MSP: MSPs typically do not implement certificate pinning for standard client deployments due to the operational overhead and risk of connectivity failures during certificate rotations. Clients in regulated industries may request pinning as part of security hardening, requiring MSPs to establish robust certificate management workflows and change control processes.

Education: Educational institutions rarely implement certificate pinning for MDM unless required by grant funding restrictions or state-level security mandates. The operational complexity typically outweighs the security benefit for K-12 environments, where the threat model is less sophisticated than enterprise or government environments.

In Addigy

Addigy supports certificate pinning for custom configuration profiles where organizations require enhanced security for specific applications or network connections. Administrators can configure pinning by specifying certificate payloads within custom profiles deployed to managed devices. Addigy does not enforce certificate pinning for the MDM enrollment profile itself, as this could create recovery challenges if certificates need emergency rotation.

When deploying certificate pinning through Addigy, admins should test configurations in pilot groups before broad deployment and establish procedures for coordinated certificate rotation. Addigy’s profile versioning and deployment controls enable staged rollouts that minimize risk during certificate updates.

The cryptographic process verifying software authenticity and integrity. Gatekeeper and iOS security rely on code signing to ensure apps are from trusted sources.

What to Know

Code signing is the cornerstone of Apple’s security model, preventing malware and unauthorized software from executing on devices. Every app, script, and system component must be signed by a trusted developer certificate before macOS or iOS will allow it to run. This creates a verifiable chain of trust from Apple’s root certificate authorities down to individual developers, ensuring that software hasn’t been tampered with after publication and comes from a known source.

For IT admins, code signing impacts software deployment strategies: unsigned or improperly signed packages will be blocked by Gatekeeper, requiring manual overrides or proper signing infrastructure. Understanding code signing is essential for troubleshooting app installation failures, managing developer certificates, and maintaining security policies that don’t inadvertently block legitimate software.

Common Scenarios

Enterprise IT: Internal custom applications and scripts must be signed with a valid Developer ID certificate to avoid Gatekeeper blocks on employee devices. IT teams either sign packages themselves using an Apple Developer account or configure policies to allow specific unsigned apps, though the latter weakens security posture.

MSP: When deploying client-specific software or custom automation scripts, MSPs must ensure all packages are properly signed or documented as exceptions. Unsigned software triggers security warnings that generate support tickets and erode user trust in IT-deployed tools.

Education: Schools deploying educational software from smaller vendors may encounter apps that lack proper notarization or code signing. IT staff must balance security requirements with the need to support specialized educational tools, often requiring explicit policy exceptions for specific apps.

In Addigy

Addigy’s software deployment tools automatically handle code signing verification during package installation. If an app fails to install due to signature issues, Addigy’s logs provide detailed error messages indicating whether the signature is invalid, expired, or untrusted. Admins can also deploy configuration profiles to manage Gatekeeper settings and allowlist specific apps, though Addigy recommends proper code signing over policy exceptions whenever possible.

An XML-based file (typically .mobileconfig) containing one or more payloads that configure settings and policies on Apple devices. Profiles can be scoped to device or user level.

What to Know

Configuration profiles are the primary mechanism for deploying and enforcing settings across managed Apple devices at scale. They enable consistent, centralized configuration of security policies, network settings, device restrictions, and application behaviors without requiring manual setup on each device. Profiles ensure compliance by enforcing policies that users cannot easily modify or bypass, and they can be remotely updated or removed as organizational needs change.

From a security perspective, configuration profiles provide a standardized, auditable method for implementing organizational policies. They create a clear separation between user preferences and administrator-enforced settings, reducing the risk of misconfiguration and ensuring that critical security controls remain in place even if users attempt to modify device settings.

Common Scenarios

Enterprise IT: Deploying Wi-Fi credentials, VPN configurations, email account settings, and security policies across corporate devices. Configuration profiles ensure new employees receive standardized device configurations and that security policies are uniformly applied across all departments.

MSP: Managing multiple client environments with different policy requirements using scoped profiles. MSPs leverage profiles to deliver client-specific configurations, implement security baselines, and demonstrate compliance with industry regulations during audits.

Education: Configuring classroom devices with content filtering, app restrictions, shared iPad settings, and managed Apple IDs. Profiles enable IT teams to prepare student devices for specific learning environments and academic programs with minimal hands-on configuration.

In Addigy

Addigy organizes configuration profiles through the Catalog and Policies sections, allowing admins to build profiles using a visual interface rather than editing raw XML. Profiles can be scoped to specific devices, Smart Groups, or organizational units, and Addigy automatically handles profile installation, updates, and removal based on Smart Group membership changes. Addigy displays profile installation status for each device and provides troubleshooting logs when profiles fail to install.

When creating custom profiles in Addigy, admins can upload .mobileconfig files directly or use built-in templates for common payloads. Addigy validates profiles before deployment and identifies potential conflicts with existing configurations, preventing common deployment errors that could leave devices in an inconsistent state.

A macOS utility that displays system logs, crash reports, and diagnostic messages for troubleshooting software and system issues. Essential for diagnosing MDM enrollment and profile issues.

What to Know

Console Application provides essential diagnostic capabilities by exposing low-level system logs that reveal the root causes of crashes, configuration failures, and authentication issues not visible in standard user interfaces. IT admins use Console to diagnose MDM enrollment failures, profile installation errors, kernel panics, and app crashes by examining detailed system messages that would otherwise remain hidden. Without Console access, troubleshooting complex macOS issues often becomes guesswork rather than evidence-based problem solving.

Common Scenarios

Enterprise IT: IT teams use Console to diagnose persistent MDM issues, authentication failures with corporate services, and unexpected application behavior. When users report vague problems like “it’s slow” or “it crashed,” Console logs provide concrete evidence of what’s actually failing and when.

MSP: MSPs rely on Console when remotely troubleshooting client Mac issues that don’t produce obvious error messages. Examining system logs helps identify failing LaunchDaemons, network authentication problems, and certificate issues without requiring on-site visits.

Education: School IT staff use Console to diagnose classroom management software failures, shared iPad syncing issues, and network authentication problems affecting student logins. The real-time log streaming helps identify problems as they occur during classroom hours.

In Addigy

Addigy’s Remote Desktop feature allows admins to access Console remotely on managed Macs, enabling real-time log review without physical access to the device. Administrators can also deploy custom scripts via Addigy that collect and upload relevant log segments for offline analysis, reducing the need for extended remote sessions.

A suite of features that enable seamless experiences across multiple Apple devices (Handoff, Universal Clipboard, AirDrop). In MDM environments, Continuity features can be managed to prevent data leakage.

What to Know

Continuity features create data leakage risks when users mix personal and corporate devices. An employee working on a corporate Mac can inadvertently copy sensitive data to their personal iPhone via Universal Clipboard, or start an email on a corporate device and finish it on a personal device via Handoff, potentially bypassing email retention policies or DLP controls. Organizations with strict data governance requirements often disable Continuity features to prevent unintentional data transfer between managed and unmanaged devices.

Common Scenarios

Enterprise IT: Corporate IT often restricts Continuity features on devices handling sensitive data—especially in finance, healthcare, or legal sectors. For general-purpose corporate devices, IT may allow Continuity between corporate-owned devices (Mac to iPhone both managed by MDM) while blocking it between corporate and personal devices. IT can also enable Continuity selectively, allowing AirDrop for productivity while blocking Universal Clipboard to prevent copy-paste data leaks.

MSP: MSPs should discuss Continuity policies during client onboarding, as preferences vary widely. Some clients want maximum productivity and accept the security trade-offs, while others prioritize data control and disable Continuity entirely. MSPs often see issues when users complain about “broken” Continuity features without realizing they were intentionally restricted for security reasons.

Education: Schools typically restrict AirDrop on student devices to prevent students from sharing inappropriate content, test answers, or large files that congest the network. Handoff and Universal Clipboard are usually less concerning in education environments and may remain enabled. Teacher devices often have Continuity features enabled to support flexible workflows between personal and school-issued devices.

In Addigy

Addigy provides granular Continuity restrictions through its Restrictions payload. Admins can disable AirDrop entirely, restrict AirDrop to contacts only, block Handoff, or prevent Universal Clipboard. These restrictions require supervised devices and apply immediately when the profile is deployed. Addigy’s interface groups Continuity-related restrictions together for easy discovery, and each restriction includes a description of its impact on user workflows.

A device ownership classification indicating the device is purchased and owned by the organization, allowing for full management capabilities.

What to Know

Corporate ownership grants IT the legal and technical authority to fully control the device, including the ability to monitor usage, enforce restrictions, remotely wipe all data, and prevent users from removing management. Corporate-owned devices enrolled through ADE automatically become supervised, unlocking over 100 additional restrictions and capabilities unavailable on personal devices. Ownership designation also affects user expectations around privacy — corporate-owned devices are subject to organizational policies without requiring user consent for management actions.

Common Scenarios

Enterprise IT: All company-purchased hardware should be added to ABM and enrolled as corporate-owned through ADE. This ensures full supervision, prevents profile removal, and allows IT to enforce compliance requirements for regulated industries. Corporate-owned devices are typically issued to employees who agree to acceptable use policies that permit monitoring and remote management.

MSP: MSPs should establish clear asset ownership records with clients and ensure corporate-owned devices are properly enrolled in ABM. When clients acquire hardware outside of authorized channels, MSPs need to determine whether devices can be added to ABM retroactively or require re-enrollment through Apple Configurator to achieve supervised status.

Education: School-owned devices (whether purchased or leased) are classified as corporate-owned and enrolled through ASM. This enables supervision, Shared iPad, and the full range of restrictions needed for classroom management and student safety. Schools typically retain ownership even when devices are assigned to specific students for the academic year.

In Addigy

Addigy automatically detects ownership type based on enrollment method (ADE-enrolled devices are corporate-owned). Admins can filter devices by ownership in Smart Groups to apply different policy sets — stricter controls for corporate-owned devices, lighter-touch management for personal BYOD devices. Ownership type is displayed in each device’s details page.

A modern protocol update where devices autonomously apply configurations based on declarations, reducing server round-trips and improving performance.

What to Know

Declarative Management represents a fundamental architectural shift in how MDM works. Traditional MDM operates imperatively — the server sends commands (“install this profile,” “update this app”) and waits for responses, creating constant back-and-forth traffic and latency. Declarative Management instead delivers a desired state to the device (“these are all the apps and settings you should have”), and the device autonomously reconciles itself against that state, only reporting back status changes or errors.

This architecture dramatically improves performance, reduces cellular data usage, and enables devices to self-heal without server intervention. If a user accidentally removes a required profile, the device automatically reinstalls it without waiting for the MDM server to detect the problem and send a remediation command. For organizations with large fleets or remote workers on unreliable networks, this reduces management overhead and improves compliance by ensuring devices maintain proper configuration even when disconnected from the server.

Common Scenarios

Enterprise IT: Deploy OS update policies that devices autonomously enforce based on maintenance windows and network conditions, eliminating the need for IT to manually schedule updates per device. Use declarative software update declarations to ensure devices stay current without constant MDM server communication, especially valuable for field workers with intermittent connectivity.

MSP: Leverage declarative management to reduce MDM infrastructure costs and improve client device responsiveness. Since devices self-manage against declarations, MSPs can support larger client fleets without proportionally increasing server capacity or bandwidth. Particularly valuable for clients with remote or mobile workforces where traditional imperative commands might timeout or fail due to network conditions.

Education: Deploy software update policies to student devices that automatically install updates during non-instructional hours without requiring constant communication with the MDM server. This reduces network congestion during school hours and ensures devices remain updated even when students take them home where school network access is limited.

In Addigy

Addigy supports Declarative Device Management (DDM) for compatible macOS and iPhones, with DDM-based software updates being the primary implementation. Admins can configure declarative update policies through Addigy’s System Updates interface, which generates the necessary declarations and delivers them to devices via the DDM protocol. Addigy automatically detects DDM-capable devices and routes policies through the appropriate protocol (DDM for supported devices, traditional MDM commands for older devices), ensuring compatibility across mixed fleets without requiring admins to manage protocol differences manually.

The DEP Protocol is Apple’s RESTful API that enables organizations to automate device enrollment and configuration through Apple Business Manager (ABM) or Apple School Manager (ASM).

What to Know

The DEP Protocol is the technical foundation for zero-touch deployment, enabling organizations to deliver fully configured devices to users without IT physically handling hardware. This dramatically reduces deployment time, eliminates manual enrollment steps prone to user error, and ensures devices are supervised and locked to MDM before first use. Without DEP Protocol integration, organizations must manually enroll devices, which cannot achieve supervision on iPhones and iPads already activated, and users can remove MDM profiles from unsupervised devices.

The protocol also enables continuous synchronization between ABM/ASM and MDM servers, allowing IT to assign newly purchased devices to the correct MDM instance and automatically apply enrollment profiles. This automation is essential for large-scale deployments and reduces the risk of misconfigured or unmanaged devices entering production environments.

Common Scenarios

Enterprise IT: IT teams integrate their MDM server with ABM using the DEP Protocol to automatically enroll corporate devices during Setup Assistant. New devices shipped directly to users from Apple or authorized resellers arrive pre-assigned to the corporate MDM, enabling remote deployment without IT touching the hardware. IT must maintain valid DEP tokens and monitor sync status to ensure device assignments flow correctly.

MSP: MSPs manage DEP Protocol integrations for multiple clients, each with separate ABM/ASM accounts and DEP tokens. Token renewal and device assignment workflows must be tracked per client to prevent assignment errors that could send devices to the wrong MDM instance. MSPs often establish standardized enrollment profiles across clients while customizing specific settings per organization.

Education: School districts use the DEP Protocol to manage large-scale iPad deployments, often with thousands of devices enrolled simultaneously at the start of each school year. The protocol enables bulk device assignments and profile updates without manual device handling. Education IT must coordinate with purchasing departments to ensure devices are ordered through ASM-compatible resellers and properly assigned before distribution to students.

In Addigy

Addigy’s MDM platform integrates with Apple Business Manager through the DEP Protocol, allowing admins to link their ABM/ASM account and automatically sync device assignments. Addigy provides guided workflows for generating and uploading DEP tokens, and monitors token expiration to alert admins before tokens expire. Device sync status is visible in the Addigy console, showing which devices have been assigned and are awaiting enrollment.

Administrators can define default enrollment settings in Addigy that apply to all DEP-enrolled devices, including Setup Assistant configuration, initial profiles, and app assignments. Addigy handles the technical protocol communication with Apple’s servers, abstracting the complexity while providing visibility into sync operations and device readiness.

Legacy term for devices enrolled through Apple’s Device Enrollment Program, now Automated Device Enrollment (ADE). Enables supervision and mandatory enrollment.

What to Know

DEP-enrolled is the historical terminology for what is now called ADE-enrolled. Apple renamed the Device Enrollment Program to Automated Device Enrollment in 2019, but many organizations, admins, and documentation still use DEP terminology. Understanding this legacy term is essential for interpreting older configuration guides, troubleshooting discussions, and system logs that haven’t been updated to current nomenclature. Functionally, DEP-enrolled and ADE-enrolled are identical—both refer to devices enrolled through Apple’s automatic enrollment infrastructure with mandatory, persistent management.

When encountering DEP references in logs, error messages, or configuration screens, admins should recognize these are equivalent to ADE. Some MDM platforms and Apple’s own diagnostic tools may still display DEP terminology internally, creating potential confusion if admins aren’t aware of the rebranding. Recognizing this equivalence ensures smooth troubleshooting and proper interpretation of device states.

Common Scenarios

Enterprise IT: IT teams reviewing enrollment logs from older devices see “DEP Profile” or “DEP enrollment” references and need to understand these represent current ADE functionality. When migrating from legacy MDM systems that use DEP terminology to newer systems using ADE terminology, IT must map equivalent concepts to ensure continuous device management during the transition.

MSP: MSPs supporting clients with long-standing device deployments encounter legacy documentation referencing DEP. When troubleshooting enrollment issues, error messages may reference “DEP server” or “DEP profile” even though the MSP’s current processes use ADE terminology. Understanding the equivalence allows accurate problem diagnosis without confusion about whether old DEP configurations still apply.

Education: Schools with iPads deployed before 2019 have documentation and support materials referencing DEP enrollment. When staff reference “DEP devices” in support tickets, IT understands they’re describing ADE-enrolled devices and applies current ADE troubleshooting procedures. Historical purchase records may list devices as “DEP-eligible,” which translates to modern ADE compatibility.

In Addigy

Addigy uses current ADE terminology throughout its interface and documentation, but understands legacy DEP references in Apple’s APIs and system responses. When Addigy communicates with Apple Business Manager or reads device enrollment states from Apple’s servers, it may receive DEP-labeled data and automatically translates this to ADE terminology for consistency. Addigy’s support documentation acknowledges DEP as a legacy term and redirects users to equivalent ADE resources.

If you see DEP references in Addigy logs or diagnostic outputs, these represent the same ADE enrollment process and should be treated identically. Addigy’s enrollment status displays use ADE terminology, but underlying Apple APIs may still use DEP internally, which Addigy handles transparently without requiring administrator intervention or awareness of the legacy naming.

An enrollment method that manages the entire device rather than creating a separate managed partition, providing comprehensive device-level control.

What to Know

Device-based enrollment contrasts with User Enrollment, where managed data lives in a separate APFS volume. With device-based enrollment, MDM manages the entire device as a single unit, enabling comprehensive control over system settings, all apps (not just managed ones), hardware features, and device-wide restrictions. This is the traditional enrollment model used by Automated Device Enrollment and manual enrollment, providing maximum management capabilities at the cost of reduced user privacy. Device-based enrollment is essential for corporate-owned devices where organizations need complete visibility and control.

The distinction matters primarily when comparing enrollment options for BYOD scenarios. Device-based enrollment on personally-owned devices gives IT access to all device information and control over personal apps, which many users find invasive. User Enrollment provides an alternative by segregating managed content, but device-based enrollment remains the only option for achieving full supervised management and accessing advanced MDM features like single app mode, AirPlay restrictions, and complete app inventory visibility.

Common Scenarios

Enterprise IT: Corporate-owned MacBooks and iPhones enroll via device-based enrollment (through ADE or manual), giving IT complete device management. IT can view all installed apps, enforce system-wide restrictions like disabling AirDrop, remotely lock or wipe the entire device, and monitor device health metrics. This comprehensive control is necessary for maintaining corporate security standards and compliance on company-owned assets.

MSP: MSPs use device-based enrollment for all client-owned devices, ensuring complete management capabilities. When clients request app installation reports or device usage analytics, device-based enrollment provides visibility into all device activity, not just managed apps. This comprehensive insight enables proactive support and detailed compliance reporting that wouldn’t be possible with User Enrollment’s privacy boundaries.

Education: School-owned iPads deployed to students use device-based enrollment, allowing complete control over device functionality. Schools restrict app installation, enforce classroom mode during instruction, and deploy educational apps device-wide. The comprehensive management ensures devices remain focused on educational purposes and prevents misuse, which wouldn’t be achievable with User Enrollment’s limited management scope.

In Addigy

All Addigy enrollments except User Enrollment are device-based, providing full device management capabilities. When you enroll devices through ADE or manual enrollment, Addigy gains complete visibility into device state, installed apps, hardware information, and system configurations. Addigy’s policies apply device-wide, affecting all users and apps rather than just a managed partition.

Addigy’s device inventory clearly distinguishes between device-based enrollments and User Enrollments, showing different management capabilities available for each. Device-based enrollments support all Addigy features including full app inventory, system extension management, and comprehensive restriction policies, while User Enrollments are automatically limited to privacy-respecting managed app controls.

MDM command that queries the device for hardware details, OS version, network info, installed apps, and security status.

What to Know

DeviceInformation is the foundation of MDM visibility and compliance enforcement. Without regular device queries, IT has no way to verify whether devices match policy requirements, detect security risks, or track asset inventory. This command provides the raw data that powers compliance dashboards, security reports, patch management workflows, and asset tracking systems. Every “Is FileVault enabled?” or “Which devices are running outdated iOS versions?” query ultimately traces back to DeviceInformation responses.

Beyond compliance, DeviceInformation queries also enable reactive support scenarios. When a user reports “my device isn’t working,” IT can query the device to instantly see battery health, storage capacity, network configuration, installed certificates, and MDM profile status — critical diagnostic data that would otherwise require verbal interrogation of non-technical users or physically examining the device.

Common Scenarios

Enterprise IT: Schedule automated DeviceInformation queries to maintain an up-to-date inventory of hardware models, OS versions, and security compliance status. Use query results to identify devices eligible for OS upgrades, flag devices with low storage that need attention, or detect unauthorized apps installed outside of approved channels. Trigger immediate queries when investigating security incidents to capture device state in real time.

MSP: Use DeviceInformation queries to populate client reporting dashboards with real-time device health metrics, warranty status, and compliance posture. Schedule recurring queries to detect when client devices drift out of compliance with service level agreements (SLA), triggering automated remediation workflows or escalation to client contacts when devices require attention.

Education: Query student devices before each semester to verify they’re running supported OS versions and have adequate storage for new course materials. Use queries to detect when shared iPads are running low on storage or battery health, triggering maintenance workflows before devices fail during class. Query classroom devices remotely to troubleshoot connectivity issues without disrupting instruction.

In Addigy

Addigy automatically issues DeviceInformation queries on a scheduled basis to keep device facts current in Addigy. Admins can also manually trigger immediate queries through the device details page or via the Addigy API for on-demand diagnostics. Addigy processes DeviceInformation responses and surfaces the data through Facts (structured device attributes), custom attributes, and compliance policies. Key device information is indexed for searching and reporting, allowing admins to quickly build Smart Groups based on hardware model, OS version, security status, or any other attribute returned by the DeviceInformation command.

The deepest restore mode for iOS and iPads that allows the device to interface with iTunes/Finder or Apple Configurator without loading the operating system or boot loader. Used for severe software issues.

What to Know

DFU Mode provides the deepest level of device restoration, bypassing all boot loaders and system software to perform firmware-level updates. This is the only recovery method that can fix devices with completely corrupted firmware, failed iOS updates that bricked the device, or bootloader failures that prevent even Recovery Mode from loading. DFU Mode is also required for certain diagnostic and forensic workflows, making it an essential last-resort recovery tool.

Common Scenarios

Enterprise IT: Corporate IT uses DFU Mode to recover company iPhones and iPads that failed during MDM enrollment or iOS updates, especially when the device won’t enter standard Recovery Mode. It’s the final option before declaring a device a total loss and requesting warranty service.

MSP: MSPs use DFU Mode when client iPhones are completely unresponsive after failed jailbreak attempts, beta profile installations, or corrupted update files. Successfully recovering devices via DFU Mode avoids depot service costs and maintains client satisfaction.

Education: School IT uses DFU Mode to recover student iPads that are completely bricked after students attempted unauthorized modifications or the device experienced catastrophic update failures. This keeps devices in service rather than sending them for costly repairs.

In Addigy

DFU Mode recovery occurs outside of MDM control, but once a device is restored via DFU Mode, Addigy’s Return to Service feature can immediately re-enroll and reconfigure the device. This ensures that after the low-level firmware restore, the device is quickly brought back under management with all policies and apps reinstalled automatically.

Automatically generated reports that capture information about app crashes, system panics, and performance issues for troubleshooting purposes.

What to Know

Diagnostic Reports provide detailed technical evidence of what caused application crashes, system hangs, kernel panics, and performance degradation. These reports contain stack traces, memory states, and system conditions at the time of failure, which are essential for identifying buggy software, incompatible drivers, or failing hardware components. Organizations use diagnostic reports to track recurring issues across fleets, document problems for vendor support cases, and prioritize software updates or patches.

Common Scenarios

Enterprise IT: IT departments collect diagnostic reports from user Macs to identify patterns in application crashes, especially after deploying new software or updates. Reports help determine if crashes are caused by conflicting software, insufficient resources, or bugs that require vendor escalation.

MSP: MSPs review diagnostic reports when troubleshooting client-reported Mac instability, using the crash logs to differentiate between application bugs, driver issues, and actual hardware failures. This prevents unnecessary hardware replacements when software fixes would resolve the problem.

Education: School IT teams monitor diagnostic reports from shared student devices to detect problematic apps or system configurations causing repeated crashes. Identifying these patterns helps IT update app versions or adjust deployment policies to improve classroom device reliability.

In Addigy

Addigy can deploy custom scripts that collect diagnostic reports from managed Macs and upload them to a central location for analysis. Administrators can also use Addigy’s Remote Desktop feature to navigate to ~/Library/Logs/DiagnosticReports on end-user devices and review crash logs in real time without requiring users to manually locate and send files.

Payload that configures FileVault disk encryption on Macs. Can enforce encryption, configure recovery key escrow to MDM, and prevent user disablement.

What to Know

Full-disk encryption is essential for protecting organizational data on lost or stolen devices. The Disk Encryption payload ensures that all data on a Mac is encrypted at rest, making it unreadable without proper authentication. Escrowing recovery keys to MDM prevents data loss scenarios where users forget passwords while maintaining IT’s ability to recover encrypted data when needed. Without enforced encryption, devices containing sensitive information create significant data breach risks and compliance violations.

FileVault encryption is required by many security frameworks and compliance standards including HIPAA, PCI-DSS, and SOC 2. Organizations that fail to encrypt devices risk severe regulatory penalties and reputational damage in the event of device theft or loss.

Common Scenarios

Enterprise IT: Enforcing FileVault on all corporate MacBooks to protect customer data, intellectual property, and confidential communications. IT teams escrow recovery keys to ensure data recovery when employees leave or forget credentials.

MSP: Implementing encryption policies across client fleets to meet industry-specific compliance requirements. MSPs use escrowed keys to assist clients with password recovery without requiring full device wipes, reducing downtime and data loss incidents.

Education: Encrypting faculty and administrative devices that store student records, financial data, and personnel information. Education institutions balance encryption enforcement with recovery key management to prevent data loss during staff transitions.

In Addigy

Addigy’s FileVault configuration options allow admins to enforce encryption, escrow recovery keys to Addigy’s secure vault, and generate compliance reports showing encryption status across the fleet. When FileVault is enabled through Addigy, recovery keys are automatically encrypted and stored, accessible only to authorized admins through the device details page.

Addigy provides detailed logging of FileVault enablement status, including failures and user deferrals. Admins can see which devices are encrypted, pending encryption, or failed to encrypt, enabling proactive remediation of compliance gaps.

A macOS application for managing, formatting, partitioning, and repairing disk drives and volumes. Available in both macOS and macOS Recovery.

What to Know

Disk Utility is the primary tool for diagnosing and repairing file system corruption, verifying disk health, erasing drives securely, and creating or modifying partition schemes. When Macs won’t boot, run slowly due to disk errors, or fail to install software, Disk Utility’s First Aid feature can detect and repair file system damage that would otherwise require professional data recovery or device replacement. It also enables secure data destruction when repurposing or retiring devices, ensuring compliance with data protection regulations.

Common Scenarios

Enterprise IT: IT teams use Disk Utility to diagnose Macs with boot failures or file system corruption, running First Aid to repair directory damage before resorting to full OS reinstalls. It’s also used to securely erase drives on decommissioned Macs to ensure sensitive corporate data isn’t recoverable.

MSP: MSPs run Disk Utility First Aid remotely or on-site when clients report slow Macs or “disk full” errors that persist after freeing space. The tool helps determine if disk replacement is needed or if file system repair will resolve the issue, avoiding unnecessary hardware costs.

Education: School IT staff use Disk Utility at the beginning and end of each school year to erase and repartition shared student Macs, ensuring clean deployments and secure removal of previous student data. First Aid is also run on lab Macs exhibiting slow performance to repair file system damage from improper shutdowns.

In Addigy

While Disk Utility must be run locally or via Recovery Mode, Addigy admins can use Remote Desktop to guide users through launching Disk Utility and running First Aid. Addigy can also deploy scripts that run command-line equivalents (diskutil) to check disk health and report S.M.A.R.T. status, helping IT proactively identify drives likely to fail before users experience data loss.

DNS is the hierarchical naming system that translates human-readable domain names into IP addresses that computers use to identify network resources.

What to Know

DNS is foundational to all network connectivity, including MDM operations. Devices must resolve DNS queries for the MDM server URL, Apple’s APNs gateways, software update servers, App Store domains, and countless other services. DNS failures prevent enrollment, block command delivery, and disable software updates. Misconfigured DNS can cause intermittent connectivity issues that are difficult to diagnose, as failures may appear inconsistent depending on which DNS server responds to queries.

In corporate environments, DNS settings are typically deployed via configuration profiles to ensure devices use internal DNS servers capable of resolving both internal resources and external services. Split DNS configurations enable devices to access internal file servers while still reaching public internet services. DNS filtering and security services (like Cisco Umbrella or Cloudflare Gateway) are often enforced at the DNS layer to block malicious domains.

Common Scenarios

Enterprise IT: Corporate devices receive DNS settings via MDM profiles that direct queries to internal DNS servers. IT must ensure these servers can resolve both internal hostnames (file servers, print servers) and external domains (apple.com, MDM server URLs, cloud services). Split-horizon DNS configurations allow the same hostname to resolve differently inside vs. outside the corporate network. DNS troubleshooting is often the first step when devices cannot enroll or check in with MDM.

MSP: MSPs managing remote workforces must balance client DNS requirements with public DNS availability. Devices outside corporate networks may use public DNS (8.8.8.8, 1.1.1.1) while VPN-connected devices use client internal DNS. MSPs should monitor DNS resolution failures as a leading indicator of network or MDM connectivity issues, and document client-specific DNS dependencies for internal resources.

Education: School networks often implement aggressive DNS filtering to comply with CIPA requirements, blocking inappropriate content at the DNS layer. Education IT must ensure filtering policies don’t inadvertently block Apple services required for MDM, software updates, or classroom apps. Student devices on guest Wi-Fi or home networks bypass school DNS, requiring device-level content filtering rather than network-level DNS blocking.

In Addigy

Addigy allows admins to deploy DNS configuration profiles that specify custom DNS servers for managed devices. Addigy provides visibility into network configuration states, helping identify devices with DNS misconfigurations that may be preventing MDM check-ins. When troubleshooting enrollment or connectivity issues, Addigy support teams often recommend verifying DNS resolution for key domains as an early diagnostic step.

Administrators can configure DNS settings within network payloads and deploy them to specific device groups or policies, enabling different DNS configurations for office vs. remote devices. Addigy’s device facts collection includes network configuration details that can reveal DNS server assignments and aid in troubleshooting connectivity problems.

A device state indicating the device has an active MDM enrollment profile and is communicating with an MDM server.

What to Know

Enrollment establishes the trust relationship between a device and its MDM server, enabling the server to push configuration profiles, install apps, run commands, and enforce policies. Without enrollment, devices operate as unmanaged consumer devices with no organizational oversight. Enrollment status directly determines whether IT can inventory, secure, or control a device.

Common Scenarios

Enterprise IT: All corporate-owned devices should be enrolled before deployment to users. Enrollment can occur automatically through ADE during Setup Assistant, or manually by installing an enrollment profile. IT teams should monitor enrollment status dashboards to catch devices that fall out of management due to profile removal or certificate expiration.

MSP: Client onboarding workflows typically include bulk enrollment of existing devices alongside ADE setup for new purchases. MSPs should track which devices are enrolled vs. awaiting enrollment to ensure complete coverage and avoid gaps in client billing or SLA compliance.

Education: Student devices are enrolled through ASM during initial provisioning or via manual profile installation for BYOD programs. Teachers and lab managers rely on enrolled status to deploy classroom apps, enable Shared iPad, and enforce content restrictions during instructional time.

In Addigy

Enrolled devices appear in the Addigy Devices list with a green status indicator when they are checking in successfully. Addigy displays the enrollment date, enrollment type (ADE, Manual, User Enrollment), and last check-in time. Devices that stop checking in may indicate profile removal, network issues, or expired MDM certificates.

A feature that prevents removal of the MDM enrollment profile without administrator authorization, ensuring continuous device management.

What to Know

Enrollment Lock ensures that corporate-owned devices remain managed and cannot be removed from MDM without administrator intervention. This prevents users from uninstalling management profiles to bypass security policies, app restrictions, or compliance requirements. For organizations that rely on MDM to enforce data protection and access controls, Enrollment Lock is essential for maintaining device security posture throughout the device lifecycle.

Without Enrollment Lock, users can simply delete the enrollment profile from Settings, immediately removing all management capabilities and creating security gaps. This is particularly problematic for devices containing sensitive corporate data or those required to meet compliance standards, as unenrolled devices become invisible to IT and unprotected by organizational policies.

Common Scenarios

Enterprise IT: Corporate iPhones and iPads are deployed with Enrollment Lock to prevent employees from removing MDM profiles to install unauthorized apps, disable security controls, or avoid monitoring. If a user attempts to remove the profile, they’re prompted for a PIN that only IT possesses, ensuring devices remain managed for their entire lifecycle.

MSP: MSPs enable Enrollment Lock on all client devices to maintain continuous management and prevent clients from accidentally or intentionally removing MDM profiles. This ensures compliance with MSP service agreements and prevents devices from becoming unmanaged without proper offboarding procedures.

Education: Students frequently attempt to remove MDM profiles to bypass content filtering, install personal apps, or disable classroom management features. Enrollment Lock prevents profile removal, ensuring student devices remain under school control and that safety controls like web filtering stay active.

In Addigy

Addigy enables Enrollment Lock automatically for devices enrolled through ADE. When users attempt to remove the enrollment profile, they’re prompted for a PIN that Addigy generates and stores securely. Admins can retrieve this PIN from the device details page if legitimate removal is needed, such as when decomm issioning a device or transferring it to another user. Addigy’s reporting shows Enrollment Lock status for all devices, helping IT verify that corporate devices maintain management protection.

A specially-signed configuration file that contains the MDM server URL, enrollment credentials, and initial device settings required to enroll a device in management.

What to Know

The enrollment profile is the critical first communication between a device and an MDM server. Without it, a device cannot establish trust with the MDM system or receive management commands. The profile is cryptographically signed to verify its authenticity and prevent tampering, ensuring devices only enroll with legitimate MDM servers. It contains essential connection details including the server URL, enrollment credentials, and the initial trust anchor certificate that enables secure communication.

Different enrollment methods use enrollment profiles in different ways. In Automated Device Enrollment, the profile is delivered automatically during Setup Assistant. For manual enrollment, users download and install the profile themselves, typically via a web portal or email. The profile’s security and delivery method directly impact enrollment success rates and the overall security posture of managed devices.

Common Scenarios

Enterprise IT: Corporate IT departments generate enrollment profiles for BYOD programs or devices that can’t use ADE. Users visit an internal enrollment portal, authenticate with their corporate credentials, and download a personalized enrollment profile. The profile may include identity certificates, Wi-Fi settings, and VPN configurations that apply during enrollment.

MSP: MSPs create client-specific enrollment profiles for manual enrollment scenarios, such as legacy devices or quick deployments. The profile is distributed via email or a secure link, allowing remote users to enroll without requiring direct IT intervention. MSPs often include branding and client-specific configurations in the profile to streamline setup.

Education: Schools distribute enrollment profiles for shared devices that weren’t purchased through Apple School Manager. Lab managers or technicians install the profile on each device manually, or students scan a QR code that installs the profile, enabling centralized management of previously unmanaged devices.

In Addigy

Addigy generates enrollment profiles automatically when you initiate manual enrollment. Users can access the enrollment profile through the Addigy enrollment URL, which authenticates the user and delivers a signed profile specific to their account. The profile includes Addigy’s MDM server URL, enrollment credentials, and initial settings defined in your enrollment configuration.

For ADE enrollments, Addigy delivers the enrollment profile automatically during Setup Assistant without user interaction. Addigy also supports creating custom enrollment profiles with additional payloads such as Wi-Fi, certificates, or VPN configurations, allowing you to pre-configure network access before full policy deployment completes.

Proprietary apps distributed via MDM (IPA/PKG files) rather than the App Store. Requires Enterprise Distribution certificates.

What to Know

Enterprise Apps enable organizations to develop and distribute internal line-of-business applications that would never be approved for public App Store distribution due to their specialized nature, proprietary integrations, or limited audience. This includes custom inventory scanners, field service tools, internal portals, or apps with deep integrations into corporate systems. Without enterprise distribution, organizations would be forced to rebuild these capabilities as web apps or rely on less secure sideloading methods.

For organizations with strict compliance requirements, Enterprise Apps also provide complete control over the distribution channel. Since these apps never pass through Apple’s public review process or servers, organizations maintain full custody of the application binaries, code signing certificates, and distribution mechanisms — critical for industries like defense, healthcare, or financial services where regulatory frameworks may prohibit third-party hosting of internal tools.

Common Scenarios

Enterprise IT: Deploy custom iOS apps for warehouse workers (inventory management, barcode scanning), field technicians (service ticketing, equipment diagnostics), or sales teams (product configurators, pricing tools). Also used to distribute beta versions of App Store apps to internal testers before public release.

MSP: Less common in MSP environments, but occasionally used to distribute white-labeled remote support apps or custom client portals that MSPs develop in-house. More frequently, MSPs help clients manage their own enterprise app distribution by configuring the necessary certificates and MDM infrastructure.

Education: Distribute custom apps for campus-specific functions like digital student ID cards, dining hall check-in systems, library resource management, or specialized research tools developed by university IT departments that wouldn’t serve a broader audience.

In Addigy

Addigy supports Enterprise App distribution through its Smart Software and Custom App deployment features. Admins upload IPA or PKG files directly to Addigy, which then hosts and distributes them via MDM commands. For iOS enterprise apps, Addigy handles the manifest URL generation required by Apple’s InstallApplication command. Addigy tracks installation status across devices and can automatically update enterprise apps when new versions are uploaded, though silent updates require the app to be managed via VPP or configured as managed software.

A feature that securely erases all data and settings from a device, returning it to factory condition. For ADE devices, enrollment can optionally be preserved.

What to Know

Erase All Content and Settings provides a fast, secure method to completely wipe an iOS or iPadOS device without requiring a computer, cables, or iTunes/Finder. Unlike factory reset via Recovery Mode, this feature preserves the installed OS version and can optionally preserve eSIM and Apple Watch pairings, making it ideal for re-deploying devices to new users without downgrading or losing cellular service. The process uses hardware encryption to instantly destroy encryption keys, ensuring data is irrecoverable even if the storage chips are physically extracted.

Common Scenarios

Enterprise IT: Corporate IT uses Erase All Content and Settings when reassigning company iPhones to new employees, ensuring the previous user’s data is completely removed while keeping the device on the approved iOS version. It’s faster than using a computer-based restore and can be initiated remotely via MDM.

MSP: MSPs use this feature to prepare client iPads for new deployments or to resolve severe software issues without requiring physical device access. The ability to trigger this remotely via MDM means devices can be wiped and prepared for re-enrollment even when users are off-site.

Education: Schools use Erase All Content and Settings at the end of each semester to wipe student iPads before redistributing them to new students. This ensures data privacy while allowing IT to quickly turn around large numbers of devices without connecting each to a computer.

In Addigy

Addigy supports remote initiation of Erase All Content and Settings via the MDM Erase Device command. Administrators can trigger this action from the Addigy dashboard, and when combined with Addigy’s Return to Service feature, devices automatically re-enroll after the erase completes, ensuring they’re immediately ready for the next user with all policies and apps pre-configured.

A device state where all user data and settings have been removed, returning the device to a clean state similar to when it was first unboxed.

What to Know

Erasing devices is critical for protecting organizational data when devices are lost, stolen, decommissioned, or reassigned to new users. Modern Apple devices use cryptographic erasure, which instantly renders data inaccessible by destroying encryption keys rather than overwriting storage sectors. This makes remote wipe capabilities essential for data breach prevention and regulatory compliance, especially for devices containing sensitive information that leave the organization’s physical control.

Organizations must balance erase capabilities with data preservation needs. While erasing protects against data exposure, it also permanently removes all user data, making it important to have clear policies about when erasure is appropriate versus other remediation options like remote lock. Supervised devices offer additional erase options, including the ability to preserve some settings during erasure for faster reprovisioning.

Common Scenarios

Enterprise IT: When an executive’s iPhone is reported lost at an airport, IT immediately issues a remote wipe command to protect confidential business communications and customer data. For device reassignments, IT erases devices between users to ensure clean handoffs with no residual data from previous owners.

MSP: When clients terminate employees with access to sensitive systems, MSPs execute remote wipes on corporate devices to ensure immediate data protection. During device lifecycle management, MSPs wipe devices before returning them to leasing companies or preparing them for resale, protecting client data from exposure.

Education: Schools erase student devices during summer break to prepare them for the next academic year, removing personal student data while preserving institutional configurations through supervised erase options. Lost or stolen devices containing student records are immediately erased to maintain FERPA compliance and protect student privacy.

In Addigy

Addigy provides remote erase commands for both iOS/iPadOS and Macs directly from the device action menu. For supervised iPhones, Addigy offers additional options to preserve data plans and eSIM configurations during erasure. Admins can view erase status in real-time, track which devices have been successfully erased, and receive confirmation when erase commands complete. Addigy’s audit logs record all erase commands for compliance documentation.

MDM command to factory reset a device. Options include preserving data plans or using ReturnToService to automatically re-enroll after wipe.

What to Know

EraseDevice is the ultimate security failsafe for lost, stolen, or compromised devices. When physical recovery is impossible or when a device contains sensitive data that must not fall into unauthorized hands, a remote wipe ensures all data is cryptographically erased and the device is returned to factory settings. This capability is often required by compliance frameworks (HIPAA, PCI-DSS, GDPR) that mandate remote wipe for devices accessing regulated data.

Beyond security incidents, EraseDevice is also essential for device lifecycle management. When employees leave, devices are reassigned, or hardware is sent for repair, a remote wipe ensures no corporate data persists. The ReturnToService option (available on supervised iPhones and iPads) automates the re-enrollment process after wipe, allowing IT to remotely “reset” devices for new users without requiring physical access — critical for organizations with remote workforces or distributed device pools.

Common Scenarios

Enterprise IT: Issue remote wipes for devices reported lost or stolen, especially those accessing sensitive corporate data or regulated systems. Use ReturnToService workflows to remotely repurpose devices between employees — erasing the previous user’s data while automatically re-enrolling the device so it’s ready for the next user without IT needing to handle the hardware. Initiate wipes on departing employee devices as part of offboarding checklists.

MSP: Execute client-authorized wipes on devices that are no longer under contract or when clients terminate service. Use ReturnToService to streamline device refreshes for clients with high employee turnover, allowing devices to be remotely reassigned without shipping hardware back to a central depot. Maintain documented wipe procedures to satisfy client compliance audits.

Education: Wipe student devices at the end of the school year to remove personal data before reassigning to new students. Use ReturnToService on shared iPad carts to quickly reset devices between class periods or semesters. Remotely wipe lost or stolen student devices to protect district data and comply with student privacy regulations like FERPA.

In Addigy

Addigy provides EraseDevice functionality through the Remote Wipe action available in each device’s management panel. Admins can configure wipe options including PIN code display (to prove the device was wiped), data plan preservation (for cellular devices), and ReturnToService re-enrollment (for supervised iPhones and iPads). When ReturnToService is enabled, Addigy automatically handles the re-enrollment flow, ensuring the device rejoins the same MDM server and receives its assigned policies after the wipe completes. All wipe commands are logged in the device’s audit history for compliance documentation.

The ability to start a Mac from an external storage device containing a bootable operating system. Security settings may need adjustment on T2/Apple Silicon Macs.

What to Know

External Boot capability allows IT to troubleshoot Macs with corrupted internal drives, test clean OS environments without affecting the primary system, or run forensic analysis without modifying the internal disk. It’s essential for diagnosing whether problems are caused by the operating system, user configuration, or actual hardware failure. External Boot is also used to run older macOS versions for software compatibility testing when the internal drive has been upgraded to a newer, incompatible OS.

Common Scenarios

Enterprise IT: IT departments boot Macs from external drives to diagnose whether user-reported issues stem from software configuration or hardware defects. This helps determine if a full wipe and reinstall is necessary or if the problem lies with failing storage hardware.

MSP: MSPs use external boot drives when servicing Macs that won’t start from the internal drive, allowing them to access user data for backup before attempting repairs. It also enables testing Macs in a known-good OS environment without modifying the client’s existing system.

Education: School IT uses external boot drives to test lab Macs exhibiting strange behavior in a clean environment, determining if the issue is specific to the installed OS or a deeper hardware problem. This speeds up troubleshooting during busy classroom support hours.

In Addigy

While external booting happens outside of MDM control, Addigy admins can use Addigy to deploy instructions or scripts that guide users through the external boot process for troubleshooting. Once the Mac is repaired and boots normally, Addigy management automatically resumes, ensuring policies and configurations remain enforced.

Apple’s video and audio calling service. In MDM environments, FaceTime can be restricted to enforce communication policies or prevent bandwidth usage.

What to Know

FaceTime restrictions are deployed to enforce corporate communication standards and preserve network bandwidth. Organizations that standardize on Zoom, Microsoft Teams, or other enterprise communication platforms often disable FaceTime to prevent fragmentation across multiple calling apps, which complicates support and reduces collaboration visibility. FaceTime video calls also consume significant bandwidth on cellular connections, making restriction common on devices with metered data plans.

Common Scenarios

Enterprise IT: Corporate IT restricts FaceTime on business-purpose devices to enforce use of corporate-approved communication platforms that integrate with call recording, compliance systems, or enterprise directories. Some organizations allow FaceTime Audio (voice-only) while blocking FaceTime Video to balance employee convenience with bandwidth management. IT often restricts FaceTime on shared devices like conference room iPads to prevent personal calls.

MSP: MSPs configure FaceTime restrictions based on client communication policies. Professional services clients often block FaceTime entirely to maintain records in centralized systems, while creative or tech clients may allow it for informal team communication. MSPs should document FaceTime policies clearly since users frequently assume FaceTime should work on any iPhone or iPad.

Education: Schools restrict FaceTime on student devices to prevent unsupervised video communication during class time and reduce potential for cyberbullying or inappropriate contact. Teacher devices typically have FaceTime enabled for professional communication. Some schools allow FaceTime only outside school hours using time-based restrictions.

In Addigy

Addigy’s Restrictions payload includes an “Allow FaceTime” toggle that completely disables FaceTime (both video and audio) when unchecked. This restriction requires a supervised iOS/iPadOS device and prevents the FaceTime app from making or receiving calls. The restriction applies immediately upon profile deployment. Addigy does not currently offer separate controls for FaceTime Audio vs. Video—disabling FaceTime blocks both modalities.

The process of completely erasing a device and restoring it to its original factory condition, removing all user data, apps, and settings.

What to Know

Factory Reset completely removes all user data, accounts, settings, and installed apps, returning the device to the same state it was in when first unboxed. This is essential when repurposing devices for new users, troubleshooting severe software corruption, or preparing devices for resale or disposal. Unlike selective data deletion, a factory reset ensures nothing from the previous user remains, protecting privacy and ensuring compliance with data security policies.

Common Scenarios

Enterprise IT: Corporate IT performs factory resets on devices being reassigned to new employees to ensure complete removal of the previous user’s corporate data, personal accounts, and any potentially compromising information. This maintains data security and provides a clean starting point for new deployments.

MSP: MSPs factory reset client devices when troubleshooting persistent issues that survive normal resets, ensuring a completely clean slate. It’s also used when returning loaner devices to inventory, guaranteeing no client data remains on shared equipment.

Education: Schools factory reset student devices between school years or when transferring devices between schools to ensure student privacy and remove any personal accounts, downloaded content, or configuration changes made during use.

In Addigy

Addigy supports remote factory reset through the MDM Erase Device command, allowing admins to initiate complete device wipes from the dashboard. When combined with Automated Device Enrollment (ADE) and Addigy’s Return to Service, devices automatically re-enroll after the reset, receiving all policies and apps without manual IT intervention.

Allows family members to share Apple subscriptions and purchases. In MDM environments, Family Sharing is typically disabled on corporate devices to prevent mixing corporate and personal data/licenses.

What to Know

Family Sharing creates data governance complications on corporate devices by allowing personal accounts to share access to iCloud storage, app purchases, subscriptions, and location data with corporate devices. If an employee enables Family Sharing on a corporate device, family members could gain access to corporate iCloud storage, receive notifications about corporate app activity, or see the device’s location through Find My. This creates privacy risks for the organization and potential confusion about which data belongs to the organization vs. the family group.

Common Scenarios

Enterprise IT: Corporate IT universally disables Family Sharing on company-owned devices to maintain clear boundaries between corporate and personal data. Allowing Family Sharing could expose corporate data to family members, create support issues when family members see corporate device notifications, or complicate license management when personal app purchases sync to corporate devices. On BYOD devices, IT may allow Family Sharing since the device is personally owned, but corporate app deployments use VPP to avoid mixing personal and corporate licenses.

MSP: MSPs disable Family Sharing by default on all client devices unless explicitly instructed otherwise. The feature creates support complexity with minimal business value, and most clients prefer clear corporate-personal separation. MSPs should explain Family Sharing restrictions during onboarding to prevent user confusion when employees attempt to share subscriptions with family members.

Education: Schools disable Family Sharing on student devices to prevent students from sharing school-purchased content with family members or accessing family-shared content that may bypass content filters. Student devices use Managed Apple IDs which don’t support Family Sharing. Teacher devices may allow Family Sharing if the school permits personal use of teacher-assigned devices.

In Addigy

Addigy’s Restrictions payload includes an “Allow Family Sharing” toggle that prevents users from joining or managing Family Sharing groups when disabled. This restriction requires a supervised device and applies immediately upon profile deployment. Disabling Family Sharing does not remove existing Family Sharing memberships—users must leave their family group manually before the restriction takes full effect.

Allows organizations to use their existing identity provider (IdP) to authenticate Managed Apple IDs, enabling single sign-on (SSO) with corporate credentials.

What to Know

Federated Authentication eliminates the need for users to remember separate passwords for Managed Apple IDs by allowing them to authenticate with their existing corporate credentials (Azure AD, Okta, Google Workspace, etc.). This improves user experience, reduces password fatigue, and simplifies IT support by centralizing authentication in the organization’s existing identity system. Federated auth also enables conditional access policies, multi-factor authentication, and centralized account lifecycle management—when a user is offboarded from the IdP, their Managed Apple ID access is automatically revoked.

For organizations deploying Managed Apple IDs at scale, federated authentication is essential for maintaining security parity with other corporate systems. Without it, Managed Apple IDs become isolated accounts with separate passwords, increasing the risk of weak passwords, credential reuse, and orphaned accounts after employee departures.

Common Scenarios

Enterprise IT: Corporate IT configures federated authentication to integrate Managed Apple IDs with Azure AD, allowing employees to sign in to iCloud, App Store, and other Apple services using their existing corporate credentials and MFA. This eliminates password management friction and ensures that deprovisioned employees lose access to Apple services immediately when their corporate account is disabled. IT typically configures federated auth during initial ABM setup to ensure all Managed Apple IDs leverage SSO from day one.

MSP: MSPs configure federated authentication for clients with existing identity providers, though some smaller clients may lack the infrastructure to support it. MSPs should educate clients about the security and user experience benefits of federated auth, especially for clients concerned about password management overhead. Setup requires coordination between the MSP, client IT, and the identity provider, so MSPs should allocate time for testing and troubleshooting during implementation.

Education: Schools configure federated authentication to integrate Managed Apple IDs with their student information systems or learning management platforms. This allows students and teachers to sign in to Apple services using their school credentials, simplifying access and ensuring that graduating students automatically lose access to school Apple IDs when their accounts are deprovisioned. Federated auth is especially valuable for schools with existing SSO infrastructure.

In Addigy

While Addigy doesn’t directly configure federated authentication (it’s set up in Apple Business Manager), Addigy supports devices using federated Managed Apple IDs without any special configuration. Users authenticate through their identity provider during device setup or when accessing iCloud services, and Addigy manages the device normally. Addigy documentation includes federated authentication setup guides that walk admins through the ABM configuration process with common IdPs like Azure AD and Okta.

Full-disk encryption for macOS. MDM can enforce FileVault, escrow recovery keys, and require encryption before allowing access to the device.

What to Know

FileVault is the primary defense against data breaches caused by lost, stolen, or improperly decommissioned Macs. Without full-disk encryption, anyone with physical access to a Mac can boot from external media and access all files, bypassing user passwords entirely. FileVault encrypts the entire startup disk using XTS-AES-128 encryption, ensuring that data remains unreadable without the correct credentials, even if the drive is removed and connected to another system.

MDM’s ability to enforce FileVault and escrow recovery keys is critical for enterprise security and compliance (HIPAA, SOC 2, GDPR). Without key escrow, a forgotten password results in permanent data loss. With proper MDM enforcement, IT can recover encrypted drives while maintaining the security benefits of encryption, balancing user convenience with organizational data protection requirements.

Common Scenarios

Enterprise IT: Corporate security policies typically mandate FileVault on all company-owned Macs. IT deploys FileVault profiles via MDM, automatically enabling encryption and escrowing recovery keys. If an employee forgets their password or leaves the company without sharing credentials, IT can use the escrowed key to unlock the drive and recover data.

MSP: MSPs enable FileVault as a baseline security control for all managed clients, particularly those in regulated industries. They use MDM to enforce encryption and centrally store recovery keys, allowing rapid response to lost device incidents without client involvement. This also simplifies decommissioning workflows, as encrypted drives can be securely wiped without multi-pass overwriting.

Education: Schools enable FileVault on staff devices that access student data or administrative systems. While student-facing devices may skip encryption to simplify device rotation and imaging, any Mac handling sensitive data (grades, attendance, IEPs) should be encrypted with MDM-escrowed recovery keys.

In Addigy

Addigy can enforce FileVault through configuration profiles, automatically enabling encryption on Macs and escrowing recovery keys to the Addigy console. Admins can view FileVault status for all devices, retrieve recovery keys for locked Macs, and set policies to defer enablement until convenient for users. Addigy also supports institutional recovery keys for organizations that prefer centralized key management over per-device escrow.

Device location and tracking service. In MDM, it’s linked to Activation Lock. Organizations can manage Activation Lock on supervised devices to prevent them from being locked to personal accounts.

What to Know

Find My enables Activation Lock, which ties a device to an Apple ID and prevents unauthorized use after a factory reset. While Activation Lock protects personal devices from theft, it creates significant challenges for corporate devices if employees lock company-owned devices to personal Apple IDs. Organizations need to either disable Find My entirely or use Managed Activation Lock (available on supervised devices) to maintain control over device security while preserving the ability to reset and redeploy devices.

For MDM-managed devices, Find My also enables Managed Lost Mode, which allows IT to remotely lock devices, display custom messages, and track device location without requiring user intervention. This is critical for recovering lost or stolen corporate devices and protecting sensitive data.

Common Scenarios

Enterprise IT: Corporate IT typically disables consumer Find My on supervised devices and enables Managed Activation Lock instead. This prevents employees from locking company devices to personal accounts while still providing theft protection through MDM-controlled Activation Lock. IT uses Managed Lost Mode through the MDM to track and recover lost devices, eliminating dependence on personal Apple IDs for device recovery.

MSP: MSPs should disable consumer Find My on all client devices to prevent orphaned Activation Locks when employees leave or personal Apple IDs change. MSPs often encounter “bricked” devices locked to former employees’ Apple IDs because Find My was not properly disabled before offboarding. Managed Activation Lock provides the same theft protection without the risk of losing administrative access to devices.

Education: Schools disable consumer Find My on student devices to prevent students from locking school-owned iPads to personal or parent Apple IDs. Schools use Managed Activation Lock to protect devices from theft while maintaining the ability to wipe and redeploy devices to new students each year. Teacher devices typically have Managed Activation Lock enabled but may allow personal Find My if the school permits personal use.

In Addigy

Addigy supports Managed Activation Lock on supervised iPhones and iPads and provides Managed Lost Mode commands for tracking and securing lost devices. Admins can enable Managed Activation Lock through device settings, and Addigy stores the bypass code securely for use during device resets. Addigy displays each device’s Activation Lock status and provides one-click Lost Mode activation with customizable lock messages and contact information. Addigy’s Restrictions payload includes a “Disable Find My” option to prevent users from enabling personal Find My on corporate devices.

A security feature that requires a password to start up from alternative startup disks, boot into Recovery Mode, or access startup options.

What to Know

Firmware Password prevents unauthorized users from bypassing macOS security by booting from external drives, accessing Recovery Mode, or entering Single User Mode. Without this protection, anyone with physical access to a Mac can bypass FileVault, reset user passwords, or extract data from the drive. For organizations with compliance requirements or high-security environments, Firmware Password is essential to ensure device-level security isn’t defeated by simple boot-time workarounds.

Common Scenarios

Enterprise IT: Corporate IT enables Firmware Password on all company Macs to prevent unauthorized access if devices are lost or stolen. This ensures that even if FileVault is bypassed or the drive is removed, corporate data remains protected and the device can’t be repurposed without IT authorization.

MSP: MSPs enable Firmware Password on client executive laptops and devices that frequently travel or contain sensitive client data. This adds a critical layer of physical security that prevents unauthorized access even if the device is lost during travel.

Education: Schools enable Firmware Password on faculty laptops and administrative Macs containing student records to comply with data protection regulations like FERPA. This prevents unauthorized students or visitors from accessing protected information by simply booting from a USB drive.

In Addigy

Addigy can deploy Firmware Password to managed Macs via MDM, allowing centralized enforcement without requiring manual configuration on each device. However, Addigy cannot remotely remove Firmware Passwords set outside of MDM, so organizations should document and escrow passwords to avoid device lockouts during service or decommissioning.

Disk Utility’s diagnostic and repair feature that checks and fixes file system errors, directory corruption, and permission issues.

What to Know

First Aid is the primary tool for diagnosing and repairing file system corruption that causes boot failures, application crashes, and file access errors. When macOS experiences unexpected shutdowns, disk errors, or failing storage hardware, First Aid can detect and repair directory damage before it leads to complete data loss. Running First Aid regularly as preventive maintenance can identify early signs of disk failure, giving IT time to back up data before catastrophic hardware failure occurs.

Common Scenarios

Enterprise IT: IT teams run First Aid on Macs exhibiting slow performance, unexpected crashes, or “disk full” errors that don’t correlate with actual storage usage. This helps distinguish between file system corruption and actual hardware failure, avoiding unnecessary disk replacements.

MSP: MSPs run First Aid as a standard diagnostic step when clients report Mac performance issues or strange behavior. Repairing file system errors remotely via Recovery Mode saves on-site visit costs and resolves many issues without hardware replacement.

Education: School IT runs First Aid on lab Macs at the beginning of each term to detect and repair file system damage from improper shutdowns during the previous semester. This preventive maintenance improves reliability during the school year.

In Addigy

While First Aid runs locally via Disk Utility or Recovery Mode, Addigy admins can deploy scripts that use the command-line diskutil verifyVolume and repairVolume commands to check disk health and attempt repairs remotely. Addigy can also alert admins to S.M.A.R.T. status failures, prompting First Aid runs before complete drive failure.

A method of restarting a device when it becomes unresponsive by forcing an immediate shutdown and restart through hardware button combinations.

What to Know

Forced Restart provides a critical emergency recovery option when devices become completely unresponsive and won’t react to normal shutdown commands. Unlike graceful shutdowns, forced restarts immediately cut power to all components, clearing locked processes and corrupted memory states that prevent normal operation. This is often the only way to recover devices experiencing kernel panics, infinite boot loops, or complete UI lockups without waiting for battery depletion.

Common Scenarios

Enterprise IT: IT teams instruct users to perform forced restarts when corporate devices freeze during critical tasks or become unresponsive after software updates. This self-service recovery option reduces help desk calls and minimizes downtime without requiring IT intervention.

MSP: MSPs guide clients through forced restarts during remote support calls when devices are completely frozen and unresponsive to mouse or keyboard input. This avoids unnecessary on-site visits for issues that can be resolved with a simple hardware button sequence.

Education: School IT trains teachers and students on forced restart procedures for classroom iPads and MacBooks that freeze during instruction. This empowers front-line users to quickly recover devices without interrupting lessons or requiring IT support.

In Addigy

While forced restarts must be performed locally by users, Addigy admins can deploy user-facing documentation, self-service guides, or support alerts that provide device-specific forced restart instructions. After a forced restart, Addigy management automatically resumes, and any pending policies or apps are re-applied.

macOS security technology that enforces code signing and notarization requirements, ensuring only trusted software runs on the Mac.

What to Know

Gatekeeper is macOS’s first line of defense against malware and untrusted software, automatically verifying that apps downloaded from the internet are signed by identified developers and have been notarized by Apple. This prevents users from unknowingly running malicious software by requiring apps to meet minimum security standards before execution. Gatekeeper operates silently in the background for most users, only presenting warnings when potentially unsafe software is detected.

For enterprise environments, Gatekeeper settings directly impact software deployment strategies. Overly restrictive policies can block legitimate internal tools, while overly permissive settings undermine security posture. Understanding Gatekeeper’s enforcement levels (App Store only, App Store and identified developers, or disabled) allows IT to balance security with operational needs, and MDM can centrally manage these settings across the fleet.

Common Scenarios

Enterprise IT: IT deploys custom internal applications or developer tools that may not be notarized. Rather than weakening Gatekeeper globally, IT uses MDM to allowlist specific apps or configure Gatekeeper to permit identified developers while still blocking unknown software. This maintains security while supporting legitimate business tools.

MSP: When onboarding new clients, MSPs audit Gatekeeper settings to ensure devices aren’t configured to allow all apps without restriction. They standardize settings across client fleets and provide guidance on properly signing internal software to avoid Gatekeeper warnings that generate unnecessary support tickets.

Education: Schools typically maintain default Gatekeeper settings to protect student devices from unauthorized software. IT staff must coordinate with teachers when deploying specialized educational apps from smaller vendors that lack proper notarization, temporarily allowing specific apps while maintaining overall protection.

In Addigy

Addigy can deploy configuration profiles to manage Gatekeeper settings, including allowlisting specific apps or adjusting enforcement levels. Admins can view Gatekeeper status in device inventory and track which apps are being blocked. When software deployment fails due to Gatekeeper, Addigy’s logs clearly indicate the rejection reason, allowing admins to take corrective action such as properly signing the app or creating a targeted policy exception.

Allows users to start a task on one device and resume on another. Can be restricted via MDM to prevent data transfer between personal and corporate devices.

What to Know

Handoff enables seamless productivity by allowing users to start work on one device and continue on another without manually transferring files or state. While this improves user experience, it creates data leakage risks when users mix personal and corporate devices. An email drafted on a corporate Mac can be finished on a personal iPhone via Handoff, potentially bypassing email retention policies, DLP controls, or compliance monitoring. Organizations with strict data governance requirements often disable Handoff to prevent unintentional data transfer outside the corporate perimeter.

Common Scenarios

Enterprise IT: Corporate IT policies on Handoff vary widely based on data sensitivity and workforce composition. Organizations with BYOD programs often disable Handoff on corporate devices to prevent work from continuing on unmanaged personal devices. Companies that issue both corporate Macs and iPhones may allow Handoff between managed devices to enhance productivity while blocking Handoff to unmanaged devices. Some organizations disable Handoff entirely for employees handling sensitive data—especially in finance, healthcare, or legal sectors.

MSP: MSPs should establish Handoff policies with each client during onboarding, as preferences vary based on industry, compliance requirements, and workforce expectations. Some clients prioritize security and disable Handoff entirely, while others optimize for productivity and accept the risks. MSPs often field support tickets from users who don’t understand why Handoff stopped working after MDM enrollment—clear communication about restrictions is essential.

Education: Schools typically leave Handoff enabled on teacher devices to support flexible workflows between personal and school-issued devices. Student devices may have Handoff restricted to prevent students from transferring work to personal devices during tests or exams. Shared student devices usually have Handoff disabled to prevent cross-contamination of work between students sharing the same iPad.

In Addigy

Addigy’s Restrictions payload includes an “Allow Handoff” toggle that disables Handoff when unchecked. This restriction requires a supervised device and prevents the device from offering or accepting Handoff sessions with other devices. The restriction applies immediately upon profile deployment. Addigy does not currently offer granular control to allow Handoff only between managed devices—Handoff is either fully enabled or fully disabled.

Testing procedures and tools that verify the proper functioning of device hardware components including memory, storage, processors, and sensors.

What to Know

Hardware Diagnostics provide definitive test results that determine whether device issues are caused by failing components like RAM, storage, sensors, or logic boards. This distinction is critical for warranty claims, avoiding unnecessary software troubleshooting when hardware replacement is required, and providing evidence for procurement to justify device upgrades. The diagnostic reference codes generated are recognized by Apple Support and required for many AppleCare service authorizations.

Common Scenarios

Enterprise IT: IT departments run hardware diagnostics on devices exhibiting crashes, graphical glitches, or overheating before attempting software fixes. This ensures resources aren’t wasted troubleshooting software when a hardware defect is the root cause, and provides documentation for warranty replacement requests.

MSP: MSPs use hardware diagnostics to quickly triage client device issues and determine whether to bill for software troubleshooting or refer the device for warranty service. The diagnostic codes provide clients with concrete evidence supporting hardware replacement recommendations.

Education: School IT runs hardware diagnostics on student and staff devices before submitting AppleCare claims, ensuring devices genuinely have hardware faults and obtaining reference codes required for service authorization. This reduces rejected claims and tracks hardware failure trends across the fleet.

In Addigy

While hardware diagnostics run independently of MDM, Addigy tracks device hardware serial numbers and warranty status, helping admins correlate diagnostic results with AppleCare eligibility. Addigy’s remote desktop and script deployment features can also guide users through the diagnostic process remotely.

HSTS is a web security policy mechanism that forces web browsers and user agents to interact with servers only over secure HTTPS connections, preventing protocol downgrade attacks.

What to Know

HSTS prevents man-in-the-middle attacks that attempt to downgrade secure HTTPS connections to unencrypted HTTP, exposing sensitive data to interception. Once a server sends an HSTS header, browsers and applications refuse to connect over HTTP for the specified duration, eliminating the brief window of vulnerability during initial connection attempts. For MDM servers handling device commands, credentials, and corporate data, HSTS provides essential protection against sophisticated network-level attacks.

Without HSTS, users or misconfigured applications might accidentally connect to MDM servers via HTTP, exposing authentication credentials or device commands in plaintext. HSTS also protects against SSL stripping attacks where attackers intercept the first HTTP request before it’s upgraded to HTTPS. For organizations with strict security requirements, HSTS is often mandated as part of security compliance frameworks.

Common Scenarios

Enterprise IT: Enterprise MDM servers should enable HSTS with long max-age values (typically 1-2 years) and include subdomains to protect all related services. IT must ensure HTTPS infrastructure is stable before enabling HSTS, as broken certificates or misconfigurations cannot be worked around once HSTS is cached by devices. Security audits often verify HSTS headers are present on MDM and web application servers.

MSP: MSPs hosting MDM infrastructure should enable HSTS on all client-facing MDM instances to meet security best practices and compliance requirements. MSPs must coordinate HSTS enablement with certificate lifecycle management to prevent client outages if certificates expire or are misconfigured. HSTS preload list submission may be required for high-security clients but requires permanent HTTPS commitment.

Education: Educational MDM deployments should enable HSTS to protect student and staff devices from network-based attacks on shared school Wi-Fi networks. Student devices on public Wi-Fi outside school are particularly vulnerable to SSL stripping attacks that HSTS prevents. Education IT should verify HSTS compatibility with any legacy systems before deployment to avoid connectivity issues with older devices or applications.

In Addigy

Addigy’s cloud-hosted MDM infrastructure implements HSTS across its service endpoints, ensuring all device communication occurs over encrypted HTTPS connections. Addigy’s HSTS headers prevent protocol downgrade attacks and protect data in transit between devices and Addigy servers. Administrators do not need to configure HSTS manually — it is enforced automatically by Addigy’s infrastructure.

For organizations deploying custom applications or internal web services through Addigy-managed devices, admins can verify HSTS implementation by inspecting server headers or using online SSL testing tools. Addigy’s security posture benefits from HSTS as part of a defense-in-depth approach to protecting MDM communications.

HTTP is the foundational application protocol for transmitting hypermedia documents on the web, while HTTPS is its secure variant that encrypts communication using TLS/SSL.

What to Know

HTTPS is absolutely non-negotiable for MDM operations. All device-to-server communication, including enrollment, command execution, inventory reporting, and profile delivery, occurs over HTTPS to protect sensitive data from interception. MDM servers must present valid TLS certificates trusted by devices, and certificate validation failures will prevent enrollment and block management commands. The shift from HTTP to HTTPS across the entire Apple ecosystem means modern devices enforce HTTPS connections through App Transport Security (ATS) policies that reject insecure HTTP connections by default.

Certificate validity, proper hostname matching, and trusted certificate authority chains are prerequisites for MDM functionality. Organizations must maintain valid certificates, renew them before expiration, and ensure intermediate certificates are properly configured. HTTPS also provides authentication — devices verify they’re connecting to the legitimate MDM server, and mutual TLS can authenticate devices to the server using client certificates.

Common Scenarios

Enterprise IT: Corporate MDM servers require valid HTTPS certificates from trusted CAs or properly deployed internal CAs with root certificates distributed to devices. IT must monitor certificate expiration and coordinate renewals to prevent service outages. Load balancers and reverse proxies must be configured to properly terminate HTTPS connections while preserving client certificate authentication if used. Certificate errors are among the most common causes of enrollment failures and check-in issues.

MSP: MSPs must manage HTTPS certificates for hosted MDM infrastructure and ensure proper certificate coverage for all client-facing domains. Wildcard or SAN certificates simplify management when hosting multiple client instances. MSPs should implement automated certificate renewal through services like Let’s Encrypt or enterprise certificate management platforms. Client-specific custom domains require coordination with client DNS and certificate provisioning processes.

Education: Educational institutions must ensure MDM server certificates are valid and trusted by student devices, including personal BYOD devices that may not trust internal CAs. Public CA certificates simplify deployment but require annual renewal and cost considerations for large deployments. School networks with SSL inspection proxies must exclude MDM traffic to prevent certificate validation failures that break enrollment and check-ins.

In Addigy

Addigy’s cloud-based MDM infrastructure handles all HTTPS certificate management automatically, using industry-standard certificates trusted by all Apple devices. Administrators do not need to manage certificates, configure web servers, or troubleshoot TLS issues — Addigy’s infrastructure maintains valid certificates and secure HTTPS endpoints. Addigy enforces HTTPS for all API access, web console access, and device communication.

For organizations connecting Addigy to internal services (LDAP, SCIM, webhooks), admins must ensure those endpoints use valid HTTPS certificates or explicitly configure trust relationships. Addigy’s platform provides visibility into connectivity issues and certificate validation failures during integration setup, helping admins troubleshoot HTTPS-related problems with external services.

Apple’s cloud storage service. In MDM, features like iCloud Drive, Photos, and Backup can be selectively enabled/disabled to prevent data leakage or manage storage on corporate devices.

What to Know

iCloud integration on corporate devices creates significant data governance challenges because organizations cannot control, audit, or recover data stored in personal iCloud accounts. Corporate documents synced to personal iCloud Drive, photos backed up to personal iCloud Photo Library, or passwords saved to personal iCloud Keychain all exist outside the organization’s security perimeter and retention policies. When employees leave, the organization has no way to reclaim corporate data stored in their personal iCloud accounts.

For regulated industries or organizations with strict data loss prevention requirements, blocking personal iCloud usage is critical for compliance with frameworks like GDPR, HIPAA, SOX, or PCI-DSS. Organizations that want to provide iCloud functionality without these risks can issue Managed Apple IDs, which provide controlled iCloud access under organizational ownership.

Common Scenarios

Enterprise IT: Corporate IT typically blocks all personal iCloud services on company-owned devices to prevent corporate data from leaving the organization’s control. Employees who need cloud storage receive corporate-approved alternatives like SharePoint, Google Drive, or Dropbox. Organizations deploying Managed Apple IDs may selectively enable iCloud Drive or other services while maintaining institutional control over the data. On BYOD devices, IT often allows personal iCloud usage but deploys app-level containerization to segment corporate and personal data.

MSP: MSPs configure iCloud restrictions based on client data governance maturity and industry regulations. Clients in healthcare, finance, or legal sectors typically demand full iCloud blocking, while tech or creative clients may allow iCloud Drive for productivity. MSPs should audit iCloud usage during client onboarding to identify devices already syncing corporate data to personal accounts, as disabling iCloud after data is synced doesn’t remove data from the cloud.

Education: Schools block personal iCloud on student devices to prevent students from syncing school-owned files to personal accounts or bypassing content restrictions through iCloud shared albums. Students receive Managed Apple IDs that provide controlled iCloud access for collaboration while maintaining school oversight. Teacher devices may allow personal iCloud if the school permits personal use of teacher-assigned devices.

In Addigy

Addigy provides granular iCloud restrictions through its Restrictions payload, allowing admins to disable iCloud entirely or selectively block individual services like iCloud Drive, iCloud Photos, iCloud Backup, iCloud Keychain, or iCloud Mail. These restrictions require supervised devices and apply immediately upon profile deployment. Addigy’s device inventory displays whether devices have iCloud accounts signed in, helping admins identify non-compliant devices. Addigy also supports deploying Managed Apple ID credentials through configuration profiles.

Automatically backs up device data to iCloud. Organizations often disable this on corporate devices to prevent company data from being stored in personal iCloud accounts.

What to Know

iCloud Backup creates significant data governance and security risks on corporate devices by automatically syncing device data—including app data, messages, photos, and settings—to personal iCloud accounts outside organizational control. Corporate emails, documents, passwords, and sensitive app data backed up to personal iCloud accounts cannot be audited, retained, or deleted by the organization. When employees leave, backup data remains in their personal accounts indefinitely, creating compliance risks and potential data breaches.

Disabling iCloud Backup is one of the most universally deployed MDM restrictions because it prevents corporate data exfiltration with minimal impact on user experience—organizations typically provide alternative backup solutions like corporate-managed cloud storage or local backups through corporate tools.

Common Scenarios

Enterprise IT: Corporate IT universally disables iCloud Backup on company-owned devices to prevent corporate data from being stored in personal iCloud accounts. Employees concerned about losing device data receive guidance on alternative backup solutions like corporate file storage, email retention, or MDM-based device configuration backups. IT may enable iCloud Backup on devices using Managed Apple IDs, where backups remain under organizational control.

MSP: MSPs disable iCloud Backup by default on all client devices as a baseline security measure. This restriction is nearly universal across industries and rarely contested by clients. MSPs should ensure backup restrictions are deployed before devices enter production to prevent corporate data from being synced to personal accounts during initial setup and usage.

Education: Schools disable iCloud Backup on student devices to prevent students from backing up school-owned content to personal or parent Apple IDs. Student devices use Managed Apple IDs which can have backup enabled while keeping data under school control. Teacher devices may allow iCloud Backup if the school permits personal use of teacher-assigned devices, though many schools disable it to maintain clear data boundaries.

In Addigy

Addigy’s Restrictions payload includes an “Allow iCloud Backup” toggle that prevents devices from backing up to iCloud when disabled. This restriction requires a supervised device and applies immediately upon profile deployment. Disabling iCloud Backup does not delete existing backups in personal iCloud accounts—users must manually delete backups if the organization wants to remove previously synced data. Addigy’s device inventory shows whether devices have iCloud Backup enabled, helping admins identify non-compliant configurations.

Cloud file storage and sync. Can be selectively enabled or disabled via MDM configuration profiles to control where corporate documents are stored.

What to Know

iCloud Drive creates data governance challenges when users save corporate files to personal iCloud accounts, removing those files from organizational backup systems, audit trails, and retention policies. Files stored in personal iCloud Drive cannot be recovered by the organization after employee departures, creating compliance risks and potential data loss. For organizations subject to data retention regulations or eDiscovery requirements, allowing personal iCloud Drive usage on corporate devices can create significant legal and compliance exposure.

Common Scenarios

Enterprise IT: Corporate IT typically disables personal iCloud Drive on company-owned devices to prevent corporate documents from being stored outside approved corporate storage systems like SharePoint, OneDrive, or Google Drive. Organizations deploying Managed Apple IDs may enable iCloud Drive while maintaining organizational control over the storage account. On BYOD devices, IT may allow personal iCloud Drive while using app-level data containerization to prevent corporate apps from saving to personal cloud storage.

MSP: MSPs configure iCloud Drive restrictions based on client data governance policies and industry requirements. Professional services clients (legal, accounting, consulting) often require complete iCloud Drive blocking to maintain client confidentiality and data retention compliance. Creative or tech clients may allow iCloud Drive for productivity, accepting the governance trade-offs. MSPs should audit whether corporate files already exist in personal iCloud Drive accounts before deploying restrictions.

Education: Schools disable personal iCloud Drive on student devices to prevent students from syncing school-owned files and assignments to personal or parent Apple IDs. Students receive Managed Apple IDs with iCloud Drive enabled under school control for collaboration and file sharing. Teacher devices may allow personal iCloud Drive if the school permits personal use, though many schools disable it to prevent mixing personal and school files.

In Addigy

Addigy’s Restrictions payload includes an “Allow iCloud Drive” toggle that prevents devices from using iCloud Drive when disabled. This restriction requires a supervised device and applies immediately upon profile deployment. Disabling iCloud Drive does not remove files already synced to personal iCloud Drive accounts—users must manually delete files if the organization wants to remove previously synced corporate data. Addigy also supports deploying Managed Apple ID configurations that enable controlled iCloud Drive access under organizational ownership.

Securely stores and syncs passwords. In MDM, this can be restricted to prevent password sync between personal and corporate devices.

What to Know

iCloud Keychain creates security and compliance risks on corporate devices by syncing passwords, credit cards, and authentication tokens to personal iCloud accounts outside organizational control. Corporate VPN credentials, internal system passwords, or multi-factor authentication tokens synced to personal iCloud Keychain remain accessible to employees after they leave the organization or switch to personal devices. This creates unauthorized access risks and complicates credential rotation during offboarding.

Organizations deploying enterprise password managers like 1Password, LastPass, or Bitwarden typically disable iCloud Keychain to enforce use of auditable, centrally-managed password solutions that integrate with corporate identity systems and support policy-based password complexity requirements.

Common Scenarios

Enterprise IT: Corporate IT disables iCloud Keychain on company-owned devices to prevent corporate passwords from syncing to personal iCloud accounts. Employees receive enterprise password managers that provide centralized credential management, audit trails, and integration with SSO systems. Some organizations allow iCloud Keychain for personal passwords (banking, social media) while using containerized work apps that store credentials in enterprise password managers.

MSP: MSPs configure iCloud Keychain restrictions based on client security maturity and password management infrastructure. Clients with enterprise password managers typically disable iCloud Keychain entirely, while smaller clients without dedicated password solutions may allow it for user convenience. MSPs should ensure iCloud Keychain restrictions are deployed before users save corporate passwords to avoid leaving credentials in personal accounts after restrictions are applied.

Education: Schools disable iCloud Keychain on student devices to prevent students from syncing school passwords to personal or parent Apple IDs. Students use Managed Apple IDs which support iCloud Keychain under school control. Teacher devices may allow personal iCloud Keychain if the school permits personal use, though many schools disable it to maintain clear security boundaries between personal and school credentials.

In Addigy

Addigy’s Restrictions payload includes an “Allow iCloud Keychain” toggle that prevents devices from using iCloud Keychain when disabled. This restriction requires a supervised device and applies immediately upon profile deployment. Disabling iCloud Keychain does not delete passwords already synced to personal iCloud Keychain—users must manually delete keychain items if the organization wants to remove previously synced credentials. Addigy supports deploying Managed Apple ID configurations that enable controlled Keychain access under organizational ownership.

Apple’s encrypted messaging service. Can be restricted via MDM to enforce corporate communication tools or prevent data leakage.

What to Know

iMessage restrictions are deployed to enforce corporate communication standards and prevent data leakage through unmonitored channels. Organizations standardizing on enterprise messaging platforms like Slack, Microsoft Teams, or corporate email often disable iMessage to consolidate business communication in auditable, retention-compliant systems. iMessage’s end-to-end encryption, while excellent for privacy, prevents organizations from monitoring for compliance violations, data leaks, or policy breaches.

iMessage also creates eDiscovery and records retention challenges because message history syncs to personal iCloud accounts outside organizational control. Corporate discussions conducted over iMessage cannot be retrieved, audited, or preserved for legal hold, creating compliance risks for regulated industries.

Common Scenarios

Enterprise IT: Corporate IT restricts iMessage on business-purpose devices to enforce use of corporate-approved communication platforms that integrate with compliance systems, provide audit trails, and support eDiscovery requirements. Some organizations allow iMessage for informal team communication while requiring formal business discussions to occur in Microsoft Teams or Slack. IT typically restricts iMessage on shared devices like conference room iPads or retail kiosks to prevent personal messaging.

MSP: MSPs configure iMessage restrictions based on client communication policies and compliance requirements. Professional services clients (legal, financial, healthcare) often block iMessage entirely to maintain communication records in centralized systems. Tech or creative clients may allow iMessage for team coordination while using enterprise platforms for client-facing communication. MSPs should clarify iMessage policies during client onboarding to prevent user confusion.

Education: Schools restrict iMessage on student devices to prevent unsupervised communication during class time, reduce cyberbullying risks, and prevent students from sharing test answers or inappropriate content. Teachers typically have iMessage enabled for professional communication. Some schools allow iMessage only outside school hours using time-based restrictions.

In Addigy

Addigy’s Restrictions payload includes an “Allow iMessage” toggle that completely disables iMessage when unchecked. This restriction requires a supervised iOS/iPadOS device and prevents the Messages app from using iMessage (though SMS/MMS remain functional on cellular devices). The restriction applies immediately upon profile deployment. Addigy does not currently offer granular controls to allow iMessage only with organizational contacts—iMessage is either fully enabled or fully disabled.

MDM command to install an app from App Store (via VPP), Enterprise source (manifest URL), or package. Supports managed configuration.

What to Know

InstallApplication enables zero-touch app deployment, allowing IT to silently provision devices with required software without requiring users to visit the App Store, authenticate, or even touch their device. This is fundamental to modern device management — users receive fully-configured, production-ready devices with all necessary apps already installed and configured. Without it, organizations would need to rely on manual user installation (error-prone, time-consuming) or physical device provisioning (doesn’t scale for remote workforces).

The command also supports critical security and compliance use cases by ensuring required apps (security agents, authentication apps, VPN clients) are present before users can access corporate resources. Combined with managed app configuration, InstallApplication can deploy pre-configured apps that are immediately usable without requiring users to know server addresses, account settings, or technical parameters that might otherwise be exposed through insecure channels.

Common Scenarios

Enterprise IT: Automatically deploy productivity suites (Microsoft 365, Google Workspace), security tools (endpoint protection, password managers), and communication apps (Teams, Slack, Zoom) to new employee devices during onboarding. Push urgent security updates or patches to existing apps across the fleet without waiting for users to manually update. Deploy beta versions of internal apps to specific user groups for testing before broad rollout.

MSP: Deploy standardized toolsets to client devices including remote management agents, backup clients, and collaboration tools specific to each client’s technology stack. Push apps to devices in response to service tickets (“user needs access to X”) without requiring physical device access or user involvement. Maintain consistent app versions across client fleets to simplify support and reduce compatibility issues.

Education: Mass-deploy educational apps (Classroom, Khan Academy, GarageBand) to student device fleets before the school year begins. Push required testing apps to student devices before exam periods, ensuring all students have the correct version and configuration. Deploy course-specific apps to classroom iPad carts when rooms are reassigned between semesters.

In Addigy

Addigy issues InstallApplication commands automatically when apps are assigned to devices or groups through the Apple Apps (VPP) catalog or Smart Software deployments. For VPP apps, Addigy handles license assignment, configuration dictionary delivery, and installation status tracking. For enterprise apps and packages, Addigy generates the necessary manifest URLs and hosts the installation payloads. Addigy monitors installation progress, retries failed installations, and reports completion status in the device’s app inventory. Admins can configure installation options like whether the app should be removable by the user or if it requires supervised mode.

MDM command that installs a configuration profile (plist) onto the device to apply settings/restrictions.

What to Know

InstallProfile is the primary mechanism for enforcing device configuration and security policies at scale. Configuration profiles contain payloads for Wi-Fi, VPN, certificates, passcode requirements, restrictions, and dozens of other settings that would be impossible to manually configure on each device. A single InstallProfile command can simultaneously configure network access, enforce security baselines, and lock down unauthorized features — instantly transforming a consumer device into a compliant corporate asset.

Profiles also provide atomic configuration management, meaning all settings within a profile are applied together and removed together. This prevents “configuration drift” where individual settings might be partially applied or removed, leaving devices in inconsistent states. When a device is unenrolled, all MDM-installed profiles are automatically removed, ensuring corporate configurations don’t persist on devices that are no longer under management.

Common Scenarios

Enterprise IT: Deploy Wi-Fi and VPN profiles to provide seamless corporate network access without requiring users to know SSIDs, passwords, or server addresses. Push certificate profiles for authenticating to internal systems, email profiles for Exchange/Office 365 access, and restriction profiles to disable features like iCloud backup or AirDrop on devices accessing sensitive data. Use passcode profiles to enforce minimum password complexity across all corporate devices.

MSP: Deploy client-specific configuration profiles including Wi-Fi (unique SSIDs/passwords per client), VPN (different endpoints per client network), and security baselines (tailored to each client’s risk tolerance and compliance requirements). Use custom profiles to configure third-party apps, system preferences, or security agents with client-specific settings that can’t be managed through standard MDM commands.

Education: Deploy restrictions profiles to lock down student devices by disabling app installation, camera access during testing, AirDrop, or Safari access during exams. Push Wi-Fi profiles to automatically connect student devices to school networks, and web content filter profiles to enforce age-appropriate browsing restrictions. Use shared iPad profiles to enable multi-user support on classroom device carts.

In Addigy

Addigy abstracts InstallProfile commands through its Profiles interface, allowing admins to build profiles using a web UI rather than hand-editing XML plists. Addigy includes pre-built profile templates for common payloads (Wi-Fi, VPN, passcode, restrictions) and supports Custom Profile uploads for advanced configurations. When profiles are assigned to devices or groups, Addigy automatically issues InstallProfile commands and tracks deployment status. Profile updates trigger automatic reinstallation, and removing a profile assignment causes Addigy to issue RemoveProfile commands to clean up the configuration.

A recovery mode that downloads macOS Recovery tools from Apple’s servers over the Internet when the local recovery partition is unavailable or corrupted.

What to Know

Internet Recovery provides a built-in recovery mechanism when the local Recovery partition is corrupted, deleted, or the internal drive has completely failed. It’s the only recovery method that works without any pre-existing bootable media, making it essential for emergency situations where traditional recovery options are unavailable. Internet Recovery also ensures devices always have access to a compatible macOS installer, regardless of local disk state.

Common Scenarios

Enterprise IT: Corporate IT relies on Internet Recovery when Macs won’t boot and standard Recovery Mode fails. However, network firewalls and proxy configurations can block Internet Recovery, so IT teams must ensure proper network exemptions for Apple’s recovery servers.

MSP: MSPs use Internet Recovery when servicing client Macs with completely corrupted or replaced drives. However, slow client internet connections can make this process take hours, so MSPs often carry bootable installers as a faster alternative.

Education: School IT uses Internet Recovery to restore lab Macs during breaks, but network bandwidth constraints mean dozens of Macs downloading macOS simultaneously can overwhelm school networks. IT teams often schedule recoveries overnight or use bootable installers instead.

In Addigy

Internet Recovery operates outside of MDM, but once a Mac is restored via Internet Recovery, devices enrolled in Automated Device Enrollment (ADE) automatically re-enter Addigy’s enrollment flow. Addigy then applies all policies, restrictions, and app installations without manual IT intervention, streamlining post-recovery device provisioning.

JSON is a lightweight, text-based data interchange format that is easy for humans to read and write and easy for machines to parse and generate.

What to Know

JSON has become the de facto standard for modern API communication, replacing older formats like XML in many contexts. Its human-readable structure makes debugging and troubleshooting easier, while its lightweight nature reduces bandwidth and processing overhead compared to more verbose formats. For MDM systems, JSON enables flexible, extensible API designs that can evolve over time without breaking existing integrations. Every modern MDM API, webhook integration, and automation script relies on JSON for data exchange.

Understanding JSON structure is essential for admins building custom integrations, parsing webhook notifications, or troubleshooting API calls. JSON’s hierarchical structure allows complex, nested data like device inventory details, user assignments, and policy configurations to be represented clearly. JSON validation and schema enforcement help catch integration errors before they reach production, improving reliability of automated workflows.

Common Scenarios

Enterprise IT: IT teams use JSON when building custom scripts that interact with MDM APIs to automate device provisioning, generate compliance reports, or synchronize user assignments from HR systems. Webhook notifications arrive as JSON payloads that IT parses to trigger automated responses like ticket creation or alerts. JSON configuration files define automation workflows, integration settings, and custom reporting queries that extend MDM platform capabilities.

MSP: MSPs leverage JSON APIs to build multi-tenant management tools that aggregate device data across client accounts, automate client onboarding workflows, and generate standardized compliance reports. JSON webhooks enable MSPs to integrate MDM events with PSA tools, alerting systems, and billing platforms. MSPs should maintain JSON parsing libraries and validation tools to ensure reliable integration development and troubleshooting across client deployments.

Education: School IT departments use JSON APIs to synchronize student rosters from SIS systems to MDM, automate device assignments based on grade levels or classrooms, and generate inventory reports for asset management. JSON-formatted webhook notifications can trigger automated device re-assignment workflows during student transfers or graduations. Education-focused integrations often involve parsing JSON responses from multiple systems (SIS, MDM, identity providers) to maintain consistent device-to-user mappings.

In Addigy

Addigy’s API exclusively uses JSON for all request and response payloads, providing comprehensive documentation with JSON schema examples and sample code. Addigy’s webhook system delivers event notifications as JSON payloads, enabling real-time integration with external systems. Administrators can use JSON-formatted API calls to automate device management tasks, retrieve inventory data, and configure policies programmatically.

Addigy’s developer documentation includes JSON payload examples for every API endpoint, complete with field descriptions and data types. Addigy’s custom facts and device facts collections are stored and retrieved as JSON objects, allowing flexible custom data storage. Integration builders can leverage Addigy’s JSON APIs to create custom dashboards, automated workflows, and advanced reporting solutions that extend platform capabilities.

JWT is a compact, URL-safe means of representing claims to be transferred between two parties, commonly used for authentication and secure information exchange.

What to Know

JWTs enable stateless authentication where servers don’t need to maintain session databases, improving scalability for distributed systems. The token itself contains encoded claims (user identity, permissions, expiration time) that can be verified cryptographically without database lookups. This makes JWTs ideal for API authentication in modern MDM platforms, where admins and automation scripts need secure, revocable access to management functions. JWTs support fine-grained authorization by embedding role and permission claims that servers can validate before processing requests.

JWTs are also critical for integrations with Apple services. App Store Connect API access requires JWT-based authentication, and many enterprise SSO implementations use JWTs as part of OpenID Connect flows. The self-contained nature of JWTs means they can be validated offline, enabling edge cases like offline API access or distributed service architectures where not all components have direct database access.

Common Scenarios

Enterprise IT: IT admins receive JWTs when authenticating to MDM APIs, which are then included in API requests as Bearer tokens in the Authorization header. These tokens typically expire after hours or days, requiring periodic re-authentication. IT must securely store JWT secrets used to sign tokens and rotate them periodically to maintain security. Custom integrations should validate JWT expiration and handle token refresh flows to avoid authentication failures during long-running automation jobs.

MSP: MSPs building multi-tenant management platforms use JWTs to securely authenticate API calls across client accounts, with token claims identifying which client context is being accessed. MSPs must implement JWT validation in custom tools to prevent token tampering or replay attacks. Service accounts used for automation should have dedicated JWT credentials with scoped permissions limiting potential damage from credential compromise. Token expiration policies should balance security (shorter lifetimes) with operational convenience (fewer re-authentication interruptions).

Education: Educational institutions integrating MDM with student information systems or identity providers encounter JWTs as part of OAuth/OpenID Connect authentication flows. School IT staff building custom roster sync scripts must understand how to obtain and refresh JWTs when calling MDM APIs. JWT-based authentication simplifies automation by eliminating password management for service accounts, but requires secure storage of signing keys or client secrets used to generate tokens.

In Addigy

Addigy’s API uses a combination of client ID and client secret credentials that follow industry-standard OAuth-like patterns, with some endpoints supporting JWT-based authentication mechanisms. Administrators generate API credentials through the Addigy console and use them to authenticate API requests. Addigy handles token generation and validation internally, abstracting the complexity of JWT management from admins.

For integrations requiring webhook verification, Addigy can sign webhook payloads allowing recipients to verify authenticity. When building custom integrations with Addigy’s API, developers should implement proper credential rotation procedures and store API secrets securely using secrets management tools rather than hardcoding them in scripts. Addigy’s API documentation provides guidance on authentication flows and credential lifecycle management.

Kerberos is a network authentication protocol that uses secret-key cryptography to provide strong authentication for client-server applications by using trusted third-party services.

What to Know

Kerberos is the authentication backbone for Active Directory environments, enabling seamless single sign-on across Windows and Mac devices. When properly configured, users authenticate once at login and automatically access file shares, intranet sites, and enterprise applications without additional password prompts. This improves user experience while maintaining security through time-limited tickets that expire and require renewal. For enterprises with Active Directory infrastructure, Kerberos integration is essential for Mac devices to participate fully in the corporate network ecosystem.

Kerberos also enables IT to enforce centralized authentication policies, track access to resources, and quickly revoke access when users leave the organization. The protocol’s mutual authentication ensures both client and server verify each other’s identity, protecting against impersonation attacks. However, Kerberos requires precise time synchronization across all systems (typically via NTP), proper DNS configuration, and careful network setup to function reliably.

Common Scenarios

Enterprise IT: Corporate Mac fleets bound to Active Directory rely on Kerberos for accessing network file shares, SharePoint sites, and internal web applications configured for integrated Windows authentication. IT must ensure DNS correctly resolves domain controllers, NTP keeps clocks synchronized within 5 minutes, and network firewalls allow Kerberos traffic (TCP/UDP port 88). Kerberos configuration profiles deployed via MDM can pre-configure realm settings and enable SSO Extension for modern authentication flows. Troubleshooting Kerberos issues typically involves checking ticket cache validity, DNS resolution, and time sync.

MSP: MSPs managing clients with mixed Windows/Mac environments must understand Kerberos configuration for Mac binding to Active Directory. Clients transitioning from on-premises AD to Azure AD need guidance on modern authentication alternatives like Azure AD SSO Extension, which provides similar SSO capabilities without traditional Kerberos binding. MSPs should document each client’s authentication architecture and maintain runbooks for Kerberos troubleshooting, as time sync and DNS issues are common culprits for authentication failures.

Education: School districts with Active Directory infrastructure use Kerberos to enable teacher and staff Macs to access network resources seamlessly. Student devices may use simplified authentication methods to avoid the complexity of Kerberos ticket management on shared devices. Educational environments often struggle with Kerberos due to network segmentation, VLAN configurations that block domain controller access, or time sync issues on Wi-Fi-only devices that sleep frequently.

In Addigy

Addigy supports deploying Kerberos configuration profiles that pre-configure realm settings, service principals, and SSO Extension parameters for Mac devices joining Active Directory environments. Administrators can define Kerberos settings within custom configuration profiles and deploy them to device policies, ensuring consistent authentication configuration across the fleet. Addigy’s device facts collection includes Active Directory binding status, helping admins identify devices with authentication issues.

For organizations moving away from traditional Active Directory binding, Addigy supports modern authentication alternatives like the Kerberos SSO Extension and Azure AD SSO Extension through custom profiles. These approaches provide SSO capabilities without the operational complexity of maintaining traditional AD bindings. Addigy’s support resources include guidance on Kerberos configuration and troubleshooting common authentication challenges in managed Mac environments.

Payload that manages allowed kernel extensions (KEXTs) on macOS. Allows pre-approval of specific KEXTs by team or bundle ID, bypassing user approval prompts.

What to Know

Kernel extensions operate at the deepest level of macOS with unrestricted access to system resources, making them powerful but potentially dangerous. macOS requires explicit user approval for KEXTs to prevent malicious software from gaining kernel-level access. The Kernel Extension Policy payload allows IT to pre-approve trusted KEXTs for enterprise software like security tools, VPN clients, and device drivers, eliminating disruptive approval prompts that confuse users and create support tickets.

Without pre-approval, users may deny necessary KEXTs out of confusion or security concerns, breaking critical enterprise software. Pre-approval also prevents users from accidentally approving malicious KEXTs disguised as legitimate software.

Common Scenarios

Enterprise IT: Pre-approving KEXTs for endpoint security software like CrowdStrike or Carbon Black, network filtering tools, and corporate VPN clients. This ensures security software deploys silently without user interaction, maintaining consistent security posture across the fleet.

MSP: Managing KEXT approvals for diverse client software portfolios, including industry-specific applications that require kernel access. MSPs maintain KEXT approval lists for each client’s approved software stack, updating policies as applications are added or removed.

Education: Approving KEXTs for classroom management software, content filtering tools, and specialized educational applications. Schools pre-approve KEXTs on shared devices to prevent student disruption and ensure consistent software functionality.

In Addigy

Addigy’s KEXT approval interface allows admins to specify allowed kernel extensions by Team ID or bundle identifier. Addigy provides templates for commonly used enterprise software and validates KEXT identifiers before deployment. When deploying software that requires KEXTs, Addigy can bundle the approval profile with the application installation to ensure seamless deployment.

Note that Apple has deprecated KEXTs in favor of System Extensions. Addigy’s catalog indicates which payloads apply to legacy KEXT-based software versus modern System Extension-based applications, helping admins plan for future macOS compatibility.

LDAP is an open, vendor-neutral application protocol for accessing and maintaining distributed directory information services over an IP network.

What to Know

LDAP is the lingua franca of enterprise directory services, enabling MDM platforms to integrate with Active Directory, OpenLDAP, and other directory systems for authentication, authorization, and data synchronization. Rather than maintaining duplicate user databases, MDM systems query LDAP directories to authenticate admins, retrieve user attributes for device assignments, and apply policies based on group memberships. This creates a single source of truth for identity and organizational structure, reducing administrative overhead and eliminating synchronization drift between systems.

LDAP integration enables sophisticated policy scoping — devices can be automatically assigned to policies based on user department, location, or role retrieved from the directory. When users change departments or leave the organization, updates in the directory automatically propagate to MDM policy assignments. LDAP also supports secure authentication through LDAP over SSL/TLS (LDAPS), protecting credentials during authentication queries.

Common Scenarios

Enterprise IT: Corporate MDM platforms integrate with Active Directory via LDAP to authenticate IT admins using their domain credentials and retrieve organizational unit structures for policy scoping. When assigning devices to users, IT queries LDAP for email addresses, department affiliations, and manager relationships to automatically apply appropriate policies. LDAP groups from AD are mapped to MDM device groups, allowing IT to manage devices by department or role without manually maintaining group memberships in multiple systems. IT must configure LDAPS (port 636) rather than plain LDAP (port 389) to protect credentials and ensure firewall rules allow MDM servers to reach domain controllers.

MSP: MSPs integrate client MDM instances with each client’s directory infrastructure via LDAP, requiring per-client configuration of bind credentials, base DNs, and search filters. MSPs should use dedicated service accounts with read-only LDAP access rather than administrator credentials to limit exposure if credentials are compromised. Multi-client MSP workflows often require mapping different LDAP schemas and attribute names across diverse client directory implementations (Active Directory, Azure AD, OpenLDAP, Google Workspace LDAP). MSPs must monitor LDAP connectivity and certificate validity to catch integration failures before they impact client operations.

Education: School districts use LDAP integration to synchronize student rosters from student information systems to MDM, automatically assigning devices based on grade level, school building, or classroom. Teachers and staff are authenticated via LDAP against district Active Directory, while students may use simplified authentication methods. Education LDAP integrations often involve complex organizational structures with multiple schools, grade levels, and role-based access requirements that must be mapped to MDM policies and device assignments.

In Addigy

Addigy supports LDAP integration for administrator authentication and user information retrieval through the Addigy Identity feature. Administrators can configure LDAP connections to Active Directory or other LDAP-compliant directories, enabling single sign-on for admin console access and automating user-device associations based on directory attributes. Addigy supports LDAPS for secure communication and provides flexible attribute mapping to accommodate different directory schemas.

When configuring LDAP integration, Addigy admins specify bind credentials, base search paths, and attribute mappings through the admin console. Addigy provides connection testing tools to validate LDAP connectivity and query results before enabling production use. Addigy’s LDAP integration enables automatic user provisioning and device assignment workflows that reduce manual administrative work while maintaining consistency with organizational directory structures.

A customizable message displayed on a locked device’s screen, typically used for lost device recovery or administrative notifications.

What to Know

Lock Screen Messages transform locked devices into potential recovery tools by displaying instructions for returning lost or stolen devices to their rightful owners. For managed devices, these messages can also display corporate contact information, legal warnings, or recovery instructions that guide finders to IT departments rather than requiring police involvement. This significantly increases the likelihood of device recovery compared to unmarked locked devices.

Common Scenarios

Enterprise IT: Corporate IT configures lock screen messages on all company devices showing internal IT contact information and legal warnings about corporate ownership. This helps honest finders return lost devices and deters theft by making it clear the device is corporate property under monitoring.

MSP: MSPs enable lock screen messages on client executive devices showing both client IT contact details and MSP emergency support numbers. This ensures lost devices can be quickly recovered and returned without interrupting business operations.

Education: Schools set lock screen messages on all student devices showing the school IT helpdesk phone number and physical address. This enables campus security or community members who find lost devices to quickly return them rather than turning them over to local authorities.

In Addigy

Addigy allows admins to remotely set or update lock screen messages via MDM, enabling dynamic messaging based on device state. When combined with Lost Mode, Addigy can display custom contact information, instructions, and even activate location tracking to aid in device recovery.

A special device state that locks the device, displays a custom message, and enables location tracking to help recover lost or stolen devices.

What to Know

Lost Mode provides a middle ground between normal operation and complete device erasure, allowing organizations to secure lost or stolen devices while maintaining the possibility of recovery. It locks the device, displays custom contact information for return, and tracks location without permanently destroying data. This is particularly valuable for devices that may have been misplaced rather than stolen, or situations where data recovery is still desired before resorting to remote wipe.

The ability to display a custom message with contact information significantly increases recovery chances by providing honest finders with a clear return path. Location tracking helps IT or security teams determine whether devices are recoverable or if they should escalate to remote wipe. For supervised devices, Managed Lost Mode offers these capabilities without depending on user-configured Find My settings, ensuring IT maintains control regardless of user preferences.

Common Scenarios

Enterprise IT: A sales representative reports a lost iPad after a client meeting. IT immediately enables Lost Mode with the company security desk phone number, tracks the device’s location, and discovers it’s still at the client office. The client calls the number on the lock screen, and the device is returned the next day. Without Lost Mode, the device would have been wiped, losing unsynchronized work data.

MSP: A client’s employee leaves a company iPhone in a rideshare vehicle. The MSP enables Lost Mode displaying the company’s IT helpdesk number. The rideshare driver finds the phone, calls the number shown on the screen, and arranges return. The MSP tracks that the device remains in a reasonable location (driver’s home) rather than moving to resale channels, confirming recovery is likely.

Education: A student loses a school iPad on the bus. IT staff enable Lost Mode with the school’s main office number. The bus driver finds the device, sees the school contact information, and returns it. Location tracking confirms the device never left school property, providing evidence that immediate erasure wasn’t necessary and saving the cost of device replacement.

In Addigy

Addigy provides Lost Mode commands for both consumer Lost Mode (iPhones with Find My enabled) and Managed Lost Mode (supervised iPhones and iPads). Admins can enable Lost Mode with custom messages and phone numbers, then track device location updates through the Addigy console. Location history provides evidence for determining whether devices are recoverable or should be escalated to remote wipe. Addigy clearly indicates which devices support which Lost Mode variant based on supervision and Find My status.

A special boot environment on Macs that provides tools for reinstalling macOS, restoring from backup, and accessing disk utilities when the main system won’t boot.

What to Know

macOS Recovery provides essential system maintenance and recovery capabilities when macOS won’t boot or is severely corrupted. It includes Disk Utility for repairing file systems, reinstall macOS for restoring the operating system, and security settings for managing Startup Security and Activation Lock. Without Recovery Mode, many troubleshooting and repair tasks would require bootable external drives or professional service, significantly increasing downtime and support costs.

Common Scenarios

Enterprise IT: IT teams guide users through accessing Recovery Mode to run Disk Utility First Aid, reinstall macOS without losing user data, or adjust startup security settings when troubleshooting boot failures or enrollment issues. Recovery Mode enables many repairs without requiring physical device access.

MSP: MSPs use Recovery Mode to remotely guide clients through macOS reinstalls, disk repairs, and NVRAM resets when Macs won’t boot normally. This avoids costly on-site visits for issues that can be resolved via Recovery Mode and phone support.

Education: School IT trains student workers and teachers to boot into Recovery Mode for common tasks like running First Aid or reinstalling macOS on lab Macs. This empowers first-tier support to resolve many issues without escalating to central IT.

In Addigy

While Recovery Mode operates outside of MDM, Addigy can deploy documentation and guides that instruct users on accessing Recovery Mode for specific troubleshooting steps. After repairs are completed and macOS boots normally, Addigy management resumes and any policies or apps that were lost are automatically reinstalled.

A general term indicating a device is under MDM control and receiving management policies and configurations.

What to Know

Managed status enables IT to enforce security policies, deploy apps and updates, monitor compliance, and respond to security incidents remotely. Managed devices benefit from centralized configuration, reduced support burden through automation, and improved security posture through enforced encryption, passcodes, and restrictions. Organizations with unmanaged devices face increased risk of data breaches, compliance violations, and inconsistent user experiences.

Common Scenarios

Enterprise IT: Corporate-owned devices are managed from day one through ADE or manual enrollment. IT relies on managed status to deploy corporate Wi-Fi, VPN, email configurations, and required security tools. Managed devices can be inventoried for compliance audits and remotely locked or wiped if lost or stolen.

MSP: Client SLAs typically specify which devices are managed and at what tier of service. MSPs track managed device counts for billing and ensure devices receive timely updates, backups, and security patches. Devices transitioning from unmanaged to managed status often require initial configuration, software removal, and policy enforcement.

Education: Student and staff devices are managed to enforce acceptable use policies, deploy educational apps, and filter content. Managed status allows schools to support devices remotely, reducing the need for students to visit IT help desks and ensuring consistent classroom readiness.

In Addigy

Addigy considers a device “managed” once it is enrolled and checking in successfully. The Devices page displays managed devices alongside their applied policies, installed apps, and compliance status. Admins can filter by managed vs. unmanaged status and run bulk actions (installs, updates, commands) exclusively on managed devices.

A security feature that prevents unauthorized use of a device by requiring the owner’s Apple ID password. MDM can bypass this on supervised devices using escrowed codes.

What to Know

Managed Activation Lock provides theft deterrence for corporate devices while maintaining IT’s ability to reuse or redeploy hardware without needing the original user’s Apple ID credentials. On supervised devices, MDM automatically escrows a bypass code that allows admins to unlock the device through their management console, avoiding scenarios where a departed employee’s iCloud account blocks device reactivation. This is essential for organizations that regularly rotate devices or need to ensure hardware can be recovered and repurposed without user cooperation.

Common Scenarios

Enterprise IT: When employees leave the organization with Find My enabled on their corporate device, Managed Activation Lock ensures IT can remotely disable the lock using the escrowed bypass code rather than chasing down former employees for their Apple ID credentials or submitting proof-of-purchase requests to Apple.

MSP: Clients often hand off used devices without ensuring they’ve been properly signed out of iCloud. MSPs rely on Managed Activation Lock bypass codes to quickly restore devices to service without delays or client involvement, especially when preparing devices for new hires or repurposing hardware.

Education: Students frequently enable Find My on school-owned iPads. Managed Activation Lock allows IT staff to clear locks during summer device rotations or when preparing devices for the next school year, avoiding lengthy unlocking procedures that would otherwise disrupt device availability.

In Addigy

Addigy automatically escrows Activation Lock bypass codes for supervised devices enrolled through ADE. Admins can retrieve bypass codes from the device details page or use the “Clear Activation Lock” action to remotely disable the lock. Addigy tracks which devices have Activation Lock enabled, providing visibility into potential deployment blockers and allowing proactive remediation before devices are reassigned.

Organization-owned Apple IDs created in ABM/ASM. They provide access to iCloud and collaboration features but are controlled by the organization and support federated authentication.

What to Know

Managed Apple IDs solve the fundamental data governance problem of personal Apple IDs on corporate devices by providing organization-owned accounts that grant access to iCloud services while maintaining institutional control. Unlike personal Apple IDs, Managed Apple IDs can be created, managed, and revoked by the organization, ensuring that data stored in iCloud Drive, Keychain, or other services remains under organizational ownership. When employees leave, the organization retains access to data stored under Managed Apple IDs and can reassign accounts or delete data as needed.

Managed Apple IDs support federated authentication, allowing users to sign in with their existing corporate credentials rather than remembering separate passwords. This integration with enterprise identity providers enables SSO, MFA, and automated account lifecycle management—when a user is deprovisioned from Azure AD or Okta, their Managed Apple ID access is automatically revoked.

Common Scenarios

Enterprise IT: Corporate IT deploys Managed Apple IDs to employees who need iCloud features like Keychain for password management, iCloud Drive for file collaboration, or Notes for cross-device note syncing. Managed Apple IDs provide these capabilities while maintaining data governance and security controls. IT configures federated authentication to integrate Managed Apple IDs with Azure AD, eliminating password management overhead and ensuring automatic access revocation during offboarding.

MSP: MSPs create Managed Apple IDs for clients who want to provide iCloud functionality without the security risks of personal Apple IDs. Setting up Managed Apple IDs requires ABM access and coordination with the client’s identity provider if using federated authentication. MSPs should establish clear Managed Apple ID lifecycle processes—who creates accounts, how they’re provisioned, and what happens to data when employees leave.

Education: Schools create Managed Apple IDs for students and teachers through Apple School Manager, providing access to iCloud, collaboration tools, and educational apps while maintaining school control. For students under 13, Managed Apple IDs are the only COPPA-compliant way to provide Apple ID functionality. Schools configure federated authentication to integrate Managed Apple IDs with student information systems, automating account creation and deprovisioning based on enrollment data.

In Addigy

Addigy supports deploying Managed Apple ID credentials through configuration profiles, allowing silent iCloud sign-in during device setup without requiring users to manually enter credentials. Addigy provides reporting on which devices have Managed Apple IDs signed in versus personal Apple IDs, helping admins enforce Managed Apple ID policies. Addigy documentation includes comprehensive guides for configuring federated authentication in ABM/ASM and deploying Managed Apple ID credentials to devices.

Apps installed and controlled by MDM. Allows for remote configuration, removal of app data upon unenrollment, and managed open-in restrictions.

What to Know

Managed Apps create a clear boundary between personal and corporate data on devices. When an app is managed, its data container is tagged as organizational property — meaning IT can remotely configure app settings, enforce data loss prevention policies, and automatically remove all app data when a device is unenrolled or reassigned. This protects corporate information while respecting user privacy, since unmanaged apps remain untouched during offboarding.

The managed state also enables advanced data governance features like managed open-in restrictions (preventing users from copying data from managed apps into unmanaged ones), per-app VPN routing (sending only corporate app traffic through the VPN tunnel), and managed pasteboard controls. Without these capabilities, organizations face significant data leakage risks as users inevitably copy sensitive documents, credentials, or customer data into personal note-taking apps, cloud storage, or messaging platforms.

Common Scenarios

Enterprise IT: Deploy managed versions of Microsoft 365, Slack, Box, or Salesforce to ensure corporate data within these apps is automatically removed when employees leave. Use managed open-in to prevent users from saving customer lists from Salesforce into their personal Dropbox or screenshotting financial data from Excel into personal photo libraries.

MSP: Configure client-facing productivity apps as managed to ensure client data is cleanly separated from the device owner’s personal apps. This is especially important in BYOD or contractor scenarios where the same device accesses both personal and multiple client environments — managed apps ensure each client’s data remains isolated and removable.

Education: Deploy managed versions of Google Classroom, Canvas, or student information systems to automatically remove all class materials, grades, and student data when a device is reassigned to a new student at the end of the school year. This prevents data leakage while avoiding the need for full device wipes between users.

In Addigy

Addigy automatically marks apps as managed when they are deployed through the Apple Apps (VPP) catalog or installed via MDM InstallApplication commands. Admins can configure managed app settings through the Apple Apps interface or by deploying managed app configuration dictionaries in Custom Profiles. When a device is unenrolled from Addigy, all managed apps and their associated data containers are automatically removed, ensuring corporate data doesn’t persist on devices that are no longer under management.

An enhanced version of Lost Mode for supervised devices. Allows admins to lock/locate devices without needing the user’s iCloud account. Does not rely on ‘Find My’.

What to Know

Managed Lost Mode provides organizations with the ability to lock and track corporate devices without depending on users’ personal iCloud accounts or Find My settings. This is critical for supervised devices where IT maintains full control over device security and recovery. Unlike consumer Lost Mode (which requires Find My to be enabled), Managed Lost Mode works independently of user configuration, ensuring that IT can always initiate device recovery procedures regardless of whether users have enabled or disabled their personal Apple ID features.

This capability is essential for responding to lost or stolen device incidents, allowing IT to immediately lock devices, display custom messages with return instructions, and track device location until recovery. The independence from user accounts means IT doesn’t need to coordinate with users or access their iCloud credentials to protect organizational data.

Common Scenarios

Enterprise IT: When an employee reports a lost iPhone or iPad, IT immediately enables Managed Lost Mode to lock the device, display contact information for security, and track its location. This protects company data while providing a path for recovery without requiring the employee’s Apple ID credentials or Find My enablement.

MSP: Clients with field devices (sales tablets, delivery iPhones) rely on Managed Lost Mode to quickly secure lost devices. MSPs enable it remotely without client involvement, tracking devices until they’re recovered or determining when to escalate to remote wipe based on location patterns.

Education: When students lose school-issued iPads, IT staff enable Managed Lost Mode to lock the device and display the school’s contact information. Location tracking helps recover devices left in classrooms or on buses, reducing hardware loss costs and preventing unauthorized access to school systems.

In Addigy

Addigy provides Managed Lost Mode as a device action for supervised iOS and iPads. Admins can enable it with a custom message and optional phone number, then track the device’s location through the Addigy console. Location updates appear automatically, and admins can disable Lost Mode remotely once the device is recovered. Addigy clearly indicates which devices support Managed Lost Mode based on supervision status.

An enrollment process where users manually install an MDM enrollment profile on their device. Commonly used for BYOD scenarios or non-ADE devices.

What to Know

Manual enrollment provides flexibility for organizations that need to manage devices not purchased through authorized resellers or devices that predate Automated Device Enrollment. It’s the primary enrollment method for BYOD programs, contractor devices, or legacy hardware that can’t leverage ADE. While manual enrollment requires more user interaction than ADE, it enables organizations to extend management to any device regardless of purchase channel or ownership model.

However, manually enrolled devices cannot be supervised, limiting the management capabilities available. They also lack the persistent enrollment of ADE devices—users can remove the MDM profile at any time, removing all management. Organizations must balance the convenience of manual enrollment against these security and management limitations, often reserving manual enrollment for low-security scenarios or personal devices where privacy concerns outweigh management needs.

Common Scenarios

Enterprise IT: Employees bring their personal MacBooks or iPhones and enroll them to access corporate email, VPN, and internal resources. IT provides an enrollment link, users authenticate with their corporate credentials, and the enrollment profile installs. The profile enforces minimum security settings like passcode requirements and disk encryption without invasively managing personal data.

MSP: MSPs managing small businesses often use manual enrollment for existing devices that weren’t purchased through Apple Business Manager. When onboarding a new client with legacy devices, the MSP sends enrollment links to each user, walking them through the installation process remotely. This allows immediate management without requiring hardware refresh.

Education: Students with personal iPads enroll manually to access school Wi-Fi, install required educational apps, and receive class materials. Schools distribute enrollment instructions during orientation, and students complete enrollment themselves. Manual enrollment respects student privacy while providing necessary institutional access.

In Addigy

Addigy provides a simple manual enrollment workflow through its enrollment portal. Administrators generate unique enrollment URLs for users, who visit the URL, authenticate, and download the enrollment profile. The profile installs with a single click, enrolling the device into Addigy. You can customize the enrollment experience with branding, pre-enrollment authentication requirements, and initial configuration profiles.

Addigy tracks manually enrolled devices separately from ADE devices, clearly indicating their unsupervised status in the device inventory. You can apply policies to manually enrolled devices, but Addigy respects the limitations of unsupervised management, automatically preventing you from deploying supervised-only restrictions or configurations.

An MDM protocol command that remotely erases all content and settings from a device, optionally preserving enrollment for automatic re-enrollment.

What to Know

MDM Erase Command provides remote device wipe capability essential for responding to lost or stolen devices, securely decommissioning devices, or resolving severe software issues without physical access. This command ensures corporate data doesn’t fall into unauthorized hands even when devices are physically unrecoverable. Unlike user-initiated factory resets, MDM Erase Command can be triggered even when the device is locked or the user is uncooperative, making it critical for security incident response.

Common Scenarios

Enterprise IT: Corporate IT issues MDM Erase Commands immediately when employees report lost or stolen devices containing sensitive data. This ensures compliance with data breach notification requirements and minimizes exposure even if the device is never physically recovered.

MSP: MSPs use MDM Erase Command to remotely wipe client devices when employees are terminated, devices are being reassigned, or severe malware infections can’t be remediated. This provides clients with documented proof of data sanitization for compliance audits.

Education: Schools issue MDM Erase Commands when student devices are reported lost or stolen, ensuring student data is protected and the device becomes useless to thieves. Combined with Activation Lock, this effectively bricks stolen devices.

In Addigy

Addigy supports MDM Erase Command through the device actions menu, allowing admins to remotely wipe devices with a single click. When combined with Automated Device Enrollment and Return to Service, erased devices automatically re-enroll in Addigy after the wipe completes, receiving all policies and apps without manual intervention.

The special configuration profile that establishes and maintains the MDM connection. Contains the enrollment payload, server URL, and identity certificates.

What to Know

The MDM profile is the foundational trust relationship that enables all device management capabilities. Without it, no MDM commands can be sent, no profiles can be deployed, and no inventory data can be collected. Unlike other profiles, the MDM profile establishes bidirectional communication between the device and management server, allowing the device to check in regularly and receive management commands.

On supervised devices, the MDM profile cannot be removed by users, ensuring that IT maintains persistent management control even if users attempt to unenroll. On unsupervised devices, users can remove the MDM profile from Settings, which completely severs the management relationship and removes all deployed profiles and restrictions.

Common Scenarios

Enterprise IT: The MDM profile is installed during device enrollment and remains for the device’s entire lifecycle within the organization. IT monitors MDM profile status to identify devices that have lost connectivity or been unenrolled, triggering alerts for potential security or compliance issues.

MSP: MSPs maintain separate MDM profiles for each client organization, ensuring proper scoping and data separation. When offboarding clients, the MDM profile removal triggers automatic cleanup of all managed configurations and applications.

Education: Student devices enrolled through Apple School Manager receive MDM profiles that persist throughout the student’s tenure. Schools monitor MDM profile status to identify devices that may have been factory reset or compromised.

In Addigy

Addigy automatically installs and manages the MDM profile during enrollment workflows. Addigy monitors MDM profile health and alerts admins when devices go offline or become unenrolled. In Addigy’s device inventory, the MDM profile status is prominently displayed, and admins can view the profile’s installation date, certificate expiration, and last check-in time.

When devices are decommissioned, Addigy provides controlled MDM profile removal workflows that properly clean up enterprise data and configurations before releasing the device. For supervised devices enrolled through ADE, the MDM profile is automatically reinstalled if removed, maintaining persistent management.

The MDM Protocol is Apple’s proprietary protocol that enables third-party servers to remotely manage iOS, iPadOS, macOS, tvOS, and watchOS devices through a standardized command and response system.

What to Know

The MDM Protocol is the foundation of all Apple device management, defining how MDM servers communicate with devices to install profiles, deploy apps, query device state, and execute commands like remote lock or wipe. Apple’s documentation of this protocol enables third-party vendors to build MDM solutions that work consistently across all Apple platforms. Without the MDM Protocol, organizations would have no standardized way to remotely manage Apple devices at scale, forcing reliance on manual configuration or proprietary management tools.

The protocol’s design ensures security and privacy by requiring devices to initiate connections to MDM servers rather than allowing servers to directly connect to devices. Commands are queued on the server, and APNs notifies devices to check in and retrieve pending commands over HTTPS. This architecture prevents MDM servers from becoming attack vectors that could push malicious commands to devices without device consent. The protocol also defines clear boundaries around what MDM can and cannot access, preserving user privacy while enabling organizational management needs.

Common Scenarios

Enterprise IT: IT teams interact with the MDM Protocol indirectly through their MDM platform’s administrative interface, but understanding protocol fundamentals helps troubleshoot issues. When devices fail to check in, IT should verify APNs connectivity and HTTPS access to the MDM server. Protocol errors in MDM logs reveal specific command failures, certificate issues, or profile conflicts that may not be apparent from the admin console. IT should understand protocol limitations — certain commands require supervision, user-approved MDM, or specific enrollment types to function properly.

MSP: MSPs may need deeper MDM Protocol knowledge when troubleshooting complex client issues or building custom integrations. Understanding how the protocol handles certificate-based authentication, command queuing, and error responses helps MSPs diagnose enrollment failures, certificate expiration issues, and command delivery problems. MSPs working with multiple MDM vendors benefit from protocol-level understanding that translates across platforms, as all Apple MDM solutions implement the same underlying protocol specification.

Education: Educational IT staff typically don’t need detailed protocol knowledge for day-to-day operations, but understanding basic protocol concepts helps troubleshoot device management issues. When shared iPads fail to receive apps or profiles, knowing that devices must check in to retrieve commands helps identify network connectivity issues. Protocol understanding also clarifies why certain features (like remote wipe) require internet connectivity — devices must reach the MDM server over HTTPS to receive and acknowledge commands.

In Addigy

Addigy’s platform is built on the Apple MDM Protocol, implementing all protocol specifications to manage devices across iOS, iPadOS, macOS, tvOS, and watchOS. Addigy handles protocol-level communication automatically, translating administrative actions in the Addigy console into appropriate MDM Protocol commands sent to devices. Administrators don’t need to understand protocol syntax or command structures — Addigy abstracts the complexity while providing visibility into command execution status and device responses.

When troubleshooting device issues, Addigy’s device timeline shows MDM command execution history, protocol-level errors, and check-in patterns that help identify connectivity or configuration problems. Addigy’s support team can analyze protocol-level logs to diagnose complex issues involving command failures, certificate problems, or enrollment errors. Addigy stays current with Apple’s protocol updates, automatically supporting new commands and capabilities as Apple releases them in MDM Protocol specification updates.

A server application that implements Apple’s MDM protocol to manage enrolled devices by sending configuration profiles, app installations, and management commands.

What to Know

The MDM server is the central control point for all device management operations. It communicates with enrolled devices via Apple’s MDM protocol, issuing commands to install apps, enforce security policies, lock or wipe devices, and query device status. Without a functioning MDM server, devices cannot receive management instructions, making it the most critical component of any Apple device management infrastructure. The MDM server maintains the trust relationship with devices through APNs (Apple Push Notification service), enabling real-time communication and instant policy enforcement.

MDM servers vary widely in capabilities, from simple open-source solutions to enterprise platforms like Addigy that provide comprehensive automation, reporting, and integrations. The choice of MDM server determines which management features are available, how efficiently deployments scale, and what level of support and reliability organizations receive. Modern MDM servers also integrate with identity providers, asset management systems, and security tools to provide holistic device lifecycle management.

Common Scenarios

Enterprise IT: Large corporations deploy commercial MDM servers with high availability, supporting thousands of devices across multiple locations. The MDM server integrates with Active Directory or Azure AD for user authentication, automatically enrolls devices via ADE, and enforces corporate security baselines. IT teams monitor server health dashboards to ensure uninterrupted device communication and management.

MSP: Managed service providers use multi-tenant MDM servers to manage devices for dozens or hundreds of clients from a single platform. Each client has isolated management policies and reporting, while the MSP maintains centralized oversight. The MDM server provides client-specific branding, separate APNs certificates, and granular access controls for client admins.

Education: Schools deploy MDM servers through Apple School Manager integration, managing iPads in shared cart scenarios and 1:1 student programs. The MDM server handles Shared iPad user assignments, app distribution via VPP, and classroom-specific restrictions. Education MDM servers often include features for managing student accounts, class rosters, and educational app deployment.

In Addigy

Addigy is a cloud-based MDM server specifically designed for Apple device management. It implements the complete MDM protocol and extends it with automation, patch management, remote support, and advanced reporting capabilities. Addigy’s MDM server infrastructure is hosted on AWS with high availability and automatic scaling, eliminating the need for organizations to maintain their own server hardware or worry about uptime.

The Addigy MDM server integrates with Apple Business Manager and Apple School Manager for automated device enrollment, manages APNs certificates automatically, and provides real-time device communication through Apple’s push notification infrastructure. All MDM commands and configurations are managed through Addigy’s web console, which provides role-based access control, audit logging, and multi-tenancy for MSPs managing multiple clients.

mDNS is a protocol that resolves hostnames to IP addresses within small networks without requiring a conventional DNS server, using multicast queries on the local network. Apple’s implementation is called Bonjour.

What to Know

mDNS/Bonjour enables zero-configuration networking where devices and services automatically advertise their availability without requiring centralized infrastructure or manual configuration. Users simply open the print dialog and see available printers, or browse network shares and find local file servers without typing IP addresses or configuring DNS entries. This dramatically improves user experience in small office and home environments where dedicated DNS servers may not exist or be practical to maintain.

However, mDNS uses multicast traffic that doesn’t route across subnets, limiting its scope to the local network segment. Enterprise networks with VLANs and network segmentation often block or filter multicast traffic for security and performance reasons, breaking Bonjour-based service discovery. IT must balance the convenience of mDNS with network security policies and decide whether to enable multicast across network boundaries or deploy alternative service discovery mechanisms.

Common Scenarios

Enterprise IT: Corporate networks typically restrict mDNS traffic between VLANs for security reasons, preventing cross-subnet service discovery. IT must decide whether to enable mDNS relay/reflection on network switches to allow Bonjour discovery across subnets, or deploy printers and services using traditional DNS and manual configuration. AirPlay-enabled conference room displays often rely on mDNS, requiring IT to ensure multicast traffic flows between user VLANs and display equipment. Print services may use Bonjour for discovery on local subnets while relying on centralized print servers with DNS names for cross-subnet access.

MSP: MSPs supporting small business clients often benefit from mDNS simplicity, as local printers and file shares automatically appear without DNS configuration. Larger client sites with multiple subnets require MSPs to configure network equipment for mDNS relay or implement alternative discovery methods. MSPs should educate clients about mDNS limitations when planning network segmentation and VLAN strategies, as overly aggressive network isolation can break convenient features users expect from Apple devices.

Education: School networks often segment student, staff, and guest VLANs for security, inadvertently breaking mDNS-based printer and AirPlay discovery. Teachers expect to AirPlay to classroom Apple TVs, but network segmentation may prevent device discovery if multicast isn’t properly configured. Education IT must balance security isolation with user experience, often requiring per-building or per-classroom mDNS configuration rather than campus-wide multicast routing. Shared iPad carts in classrooms benefit from mDNS-based automatic printer discovery without requiring per-device print queue configuration.

In Addigy

Addigy-managed devices use mDNS/Bonjour for local service discovery like printer detection and AirPlay functionality, following standard macOS and iOS behavior. Administrators don’t configure mDNS through Addigy directly — it’s a network-level protocol that functions automatically when network infrastructure permits multicast traffic. When troubleshooting service discovery issues, Addigy support can help identify whether network policies are blocking multicast traffic or whether device-level configurations need adjustment.

For organizations deploying printers through Addigy, admins can configure printer profiles that specify printer queues explicitly rather than relying on Bonjour discovery. This approach works across network segments and eliminates dependence on mDNS, providing more predictable printer deployment in complex enterprise networks. Addigy’s device facts collection can reveal network configuration details that may impact mDNS functionality.

Tools and techniques for diagnosing network connectivity issues that may affect MDM communication, Internet access, and cloud service connectivity.

What to Know

Network Diagnostics tools help IT identify whether connectivity problems stem from local device configuration, network infrastructure issues, DNS failures, or ISP problems. This distinction is critical for efficient troubleshooting, as it prevents wasted time reconfiguring devices when the actual problem is a broader network outage or misconfigured DHCP server. Built-in tools like Network Utility, Wireless Diagnostics, and ping/traceroute provide concrete evidence of where network failures occur.

Common Scenarios

Enterprise IT: IT departments use Network Diagnostics to differentiate between individual device configuration problems and campus-wide network issues. This helps determine if the solution is reconfiguring the device, adjusting Wi-Fi profiles via MDM, or escalating to network infrastructure teams.

MSP: MSPs use Network Diagnostics to remotely troubleshoot client connectivity issues and determine if problems are caused by client devices, local network configuration, or ISP failures. This ensures billable hours are spent on actual client issues rather than ISP outages outside the MSP’s control.

Education: School IT uses Wireless Diagnostics on MacBooks experiencing connectivity problems in specific classrooms to identify Wi-Fi dead zones, channel interference, or access point failures. This data drives infrastructure upgrades and access point placement decisions.

In Addigy

Addigy can deploy custom scripts that run network diagnostic commands and upload results, enabling centralized analysis of connectivity issues across the fleet. Addigy’s Remote Desktop feature also allows admins to run Network Utility and Wireless Diagnostics remotely, troubleshooting connectivity problems without physical device access.

NTP is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks.

What to Know

Accurate time is non-negotiable for secure communications. Certificate validation checks timestamps to verify certificates are within their valid period, and even slight clock drift can cause valid certificates to appear expired or not yet valid. Kerberos authentication requires client and server clocks to be within 5 minutes of each other, and larger time skew causes authentication failures. Audit logs, troubleshooting timelines, and security incident investigations all rely on accurate timestamps across systems. Without synchronized time, distributed systems cannot reliably correlate events or establish causality.

Time drift can occur gradually on devices that sleep frequently or remain disconnected from networks for extended periods. Devices with incorrect clocks experience enrollment failures, unable to validate MDM server certificates, and authentication issues when accessing network resources. MDM can enforce time synchronization settings, but network firewalls must permit NTP traffic (UDP port 123) for devices to reach time servers.

Common Scenarios

Enterprise IT: Corporate networks typically allow devices to sync with external NTP servers (like time.apple.com) or provide internal NTP servers synchronized to authoritative sources. IT must ensure firewalls permit outbound NTP traffic and that internal time servers are reliably synchronized to prevent cascading time errors across the fleet. Devices traveling between time zones may experience time-related authentication failures if timezone detection is incorrect or disabled. Certificate validation errors often trace back to incorrect system clocks that make valid certificates appear expired.

MSP: MSPs should verify time synchronization when troubleshooting client enrollment failures or authentication issues. Devices with incorrect clocks often exhibit multiple seemingly unrelated problems that all stem from time skew. MSPs managing air-gapped or highly restricted networks must ensure clients provide accessible NTP servers, as devices cannot sync time without network access. Certificate expiration monitoring should account for device clock accuracy, as incorrectly set clocks may not detect approaching certificate expiration until failures occur.

Education: School networks often restrict outbound traffic aggressively, inadvertently blocking NTP and causing time drift on student devices. Shared iPads that sleep for extended periods may experience significant clock drift if they cannot reach time servers upon wake. Education IT should configure MDM to permit time.apple.com access or provide internal NTP servers accessible to all device VLANs. Time synchronization issues manifest as “Certificate not valid” errors during app downloads or profile installations.

In Addigy

Addigy-managed devices follow standard Apple behavior for time synchronization, typically using time.apple.com unless configured otherwise. Administrators can deploy custom NTP configuration profiles if organizational policy requires specific time servers. Addigy’s device facts collection includes system time information that can reveal devices with significant clock drift. When troubleshooting certificate validation errors or authentication failures, Addigy support often checks device time accuracy as an early diagnostic step.

For organizations with strict network controls that block external NTP, Addigy can help configure custom time server settings deployed via MDM profiles. Addigy’s monitoring can identify devices that haven’t checked in for extended periods, which may have experienced clock drift that prevents successful MDM communication.

A troubleshooting procedure that resets Mac system settings stored in non-volatile memory, including startup disk selection, display resolution, and time zone.

What to Know

NVRAM Reset resolves persistent issues caused by corrupted system settings that survive normal reboots, including incorrect display resolution, failure to recognize Bluetooth devices, startup disk selection problems, and audio output issues. When Macs exhibit strange behavior that doesn’t match their configuration, corrupted NVRAM is often the culprit. Resetting NVRAM is a low-risk troubleshooting step that often resolves mysterious issues without requiring operating system reinstalls or data loss.

Common Scenarios

Enterprise IT: IT teams guide users through NVRAM resets when Macs won’t remember startup disk selections, display settings keep reverting, or audio output devices aren’t recognized after reboots. This resolves many “weird behavior” help desk tickets without requiring physical device access.

MSP: MSPs use NVRAM reset as a standard troubleshooting step for client Macs exhibiting boot issues, display problems, or hardware recognition failures. It’s a quick procedure that resolves many issues remotely without requiring on-site visits.

Education: School IT performs NVRAM resets on lab Macs that won’t boot from the correct disk, have incorrect display settings, or fail to recognize projectors and classroom displays after reboots. This is especially common on shared Macs that experience improper shutdowns.

In Addigy

While NVRAM reset requires local user action (holding specific keys during boot), Addigy can deploy user-facing documentation and self-service guides that provide clear instructions. After NVRAM reset, any MDM-managed settings like Wi-Fi profiles and certificates are automatically reapplied by Addigy.

OAuth is an open standard authorization protocol that enables applications to obtain limited access to user accounts on an HTTP service without exposing user credentials.

What to Know

OAuth enables secure, delegated access where applications can access resources on behalf of users without ever seeing or storing user passwords. Instead of sharing credentials with every application, users authenticate once with the identity provider and grant specific permissions to applications through access tokens. This reduces credential exposure risk, enables fine-grained permission control, and allows users to revoke application access without changing passwords. For MDM platforms, OAuth integration with cloud identity providers enables single sign-on, automated user provisioning, and seamless integration with enterprise authentication systems.

OAuth 2.0 (the current standard) supports various authorization flows optimized for different scenarios — web applications, mobile apps, server-to-server communication, and device authorization. Token-based authentication eliminates the need for applications to store user credentials, improving security and compliance posture. OAuth also enables centralized audit trails showing which applications access what resources, supporting security monitoring and compliance reporting.

Common Scenarios

Enterprise IT: Corporate MDM platforms integrate with Azure AD or Okta via OAuth to enable SSO for administrator console access and automate user provisioning based on directory group memberships. OAuth tokens secure API integrations between MDM and other enterprise systems (ticketing, asset management, SIEM). IT must register MDM as an OAuth client in the identity provider, configuring redirect URIs and permission scopes appropriate for MDM operations. Refresh token management and token expiration policies require attention to prevent integration failures when tokens expire.

MSP: MSPs leverage OAuth to integrate client MDM instances with each client’s identity provider, enabling MSP technicians to access multiple client accounts through federated authentication. OAuth simplifies multi-tenant management by eliminating per-client credential management and enabling standardized authentication flows across diverse client identity systems. MSPs should implement OAuth best practices including secure client secret storage, proper scope limitation, and token refresh logic in custom integrations.

Education: School districts use OAuth to integrate MDM with Google Workspace for Education or Microsoft 365 Education, automatically syncing student and staff accounts, class rosters, and organizational units. OAuth-enabled integrations allow education admins to authenticate to MDM using their existing school credentials. OAuth scopes must be carefully configured to access only necessary directory information while respecting student privacy regulations like FERPA and COPPA.

In Addigy

Addigy supports OAuth-based authentication for administrator SSO, integrating with identity providers like Okta and Azure AD to enable single sign-on for the Addigy console. Administrators authenticate through their corporate identity provider, and Addigy receives OAuth tokens that establish authenticated sessions. Addigy’s Addigy Identity feature leverages OAuth protocols for directory integration, enabling automated user provisioning and device assignment based on identity provider data.

When configuring OAuth integrations, Addigy admins provide client credentials from their identity provider and configure the appropriate permission scopes. Addigy handles OAuth token management, refresh flows, and error handling automatically. Addigy’s API can be accessed using OAuth-style authentication patterns, enabling custom integrations that follow industry-standard security practices for API access control.

OCSP is an internet protocol used for obtaining the revocation status of an X.509 digital certificate without requiring Certificate Revocation Lists (CRLs).

What to Know

OCSP enables real-time verification that certificates haven’t been revoked due to compromise, policy violations, or other security concerns. When establishing HTTPS connections, devices query OCSP responders to verify the certificate’s current validity status before trusting it. This prevents acceptance of compromised certificates that may have been revoked after issuance but before natural expiration. Without OCSP, devices would rely solely on periodic CRL downloads, creating windows where revoked certificates could still be accepted as valid.

OCSP is particularly important for MDM server certificates and code signing certificates. If an MDM server certificate is compromised and revoked, OCSP checks prevent devices from trusting the compromised server. However, OCSP introduces network dependencies — devices must reach OCSP responders to validate certificates, and OCSP responder failures or network blocks can prevent certificate validation. OCSP stapling allows servers to cache OCSP responses and present them during TLS handshakes, reducing client dependencies on OCSP responders.

Common Scenarios

Enterprise IT: Corporate firewalls must allow outbound HTTPS traffic to OCSP responders (typically hosted by certificate authorities) for certificate validation to function. Organizations using internal CAs must deploy accessible OCSP responders or configure certificate profiles to disable OCSP checks (reducing security). OCSP failures manifest as certificate validation errors that prevent HTTPS connections, enrollment failures, or app installation blocks. IT should monitor OCSP responder accessibility and consider implementing OCSP stapling on web servers to reduce client dependencies on external OCSP services.

MSP: MSPs troubleshooting certificate errors should verify client networks permit OCSP traffic to certificate authority responders. Organizations with aggressive firewall policies may inadvertently block OCSP, causing widespread certificate validation failures across the managed fleet. MSPs managing multiple clients with different CA providers must understand each CA’s OCSP responder URLs and ensure appropriate firewall rules. OCSP soft-fail policies allow connections to proceed if OCSP responders are unreachable, balancing security with operational resilience.

Education: School networks with content filtering often block or interfere with OCSP traffic, causing certificate validation issues for student and teacher devices. Education IT should ensure OCSP responder domains are allowlisted in filtering policies to prevent blocking certificate validation traffic. Student devices on home networks or public Wi-Fi depend on accessible OCSP responders for certificate validation, and network-level blocks can prevent app installation or profile deployment.

In Addigy

Addigy’s infrastructure uses certificates with OCSP support, and managed devices perform standard certificate validation including OCSP checks when connecting to Addigy servers. Addigy’s HTTPS certificates include OCSP responder URLs in certificate metadata, allowing devices to verify certificate validity in real-time. Administrators don’t need to configure OCSP directly — it operates automatically as part of standard certificate validation processes.

When troubleshooting enrollment or connectivity issues, Addigy support may investigate whether network policies block OCSP traffic to certificate authorities. Organizations deploying custom certificates or internal CAs through Addigy should ensure their certificates include valid OCSP responder information or implement alternative revocation checking mechanisms to maintain security without breaking device connectivity.

OpenID Connect is an identity layer built on top of OAuth 2.0 that enables clients to verify the identity of end-users based on authentication performed by an authorization server and obtain basic profile information.

What to Know

OpenID Connect (OIDC) combines OAuth’s authorization framework with standardized identity verification, enabling single sign-on across web applications and services. While OAuth provides authorization (“what can this app do?”), OpenID Connect adds authentication (“who is this user?”), making it a complete solution for modern identity management. OIDC standardizes how applications retrieve user profile information, reducing integration complexity and enabling interoperability across identity providers (Okta, Azure AD, Google, etc.). For MDM platforms, OIDC enables administrator SSO, eliminating separate credential management and enabling centralized access control through corporate identity systems.

OIDC uses JSON Web Tokens (JWTs) to convey identity information securely, including user attributes like email, name, and group memberships. These ID tokens are cryptographically signed, preventing tampering and enabling verification without callbacks to the identity provider. OIDC also supports session management and logout propagation, allowing users to log out from MDM consoles and have that logout propagate to other connected applications.

Common Scenarios

Enterprise IT: Corporate MDM platforms integrate with Azure AD or Okta using OpenID Connect to enable SSO for IT admins, eliminating separate MDM passwords and enabling consistent access control policies. IT configures OIDC by registering the MDM platform as a client in the identity provider, specifying redirect URIs and permission scopes. Multi-factor authentication enforced at the identity provider automatically applies to MDM console access through OIDC integration. Role-based access control can leverage OIDC claims to map identity provider groups to MDM administrator roles.

MSP: MSPs leverage OIDC to enable technicians to authenticate across multiple client MDM instances using federated identity, eliminating per-client credential management. OIDC enables just-in-time provisioning where administrator accounts are created automatically when users first authenticate, reducing onboarding overhead. MSPs should implement OIDC best practices including secure redirect URI configuration, proper scope limitation, and session timeout policies that balance security with operational convenience.

Education: School districts integrate MDM with Google Workspace or Microsoft 365 using OpenID Connect, allowing IT staff to access MDM consoles using existing school credentials. OIDC simplifies administrator lifecycle management — when staff leave or change roles, access changes in the identity provider automatically affect MDM access. Educational institutions must configure OIDC scopes appropriately to access necessary directory information while complying with student privacy regulations.

In Addigy

Addigy supports OpenID Connect integration for administrator single sign-on, enabling organizations to integrate with identity providers like Okta and Azure AD. Administrators configure OIDC by providing identity provider details, client credentials, and authorization/token endpoints through the Addigy admin console. Once configured, users can log into Addigy using their corporate credentials, with authentication handled by the identity provider through the OIDC flow.

Addigy’s OIDC implementation supports standard OIDC claims for user identification and attribute mapping, enabling role-based access control based on identity provider group memberships. Addigy handles OIDC token validation, refresh flows, and session management automatically, abstracting protocol complexity from admins while maintaining security best practices. Organizations can enforce MFA at the identity provider level, with those security policies automatically applying to Addigy console access through OIDC integration.

Payload that enforces password/passcode requirements on managed devices (length, complexity, rotation, etc.). Critical for securing device access and encryption keys.

What to Know

Passcode policies are the first line of defense against unauthorized physical access to devices and encrypted data. Strong passcode requirements prevent attackers from easily guessing or brute-forcing device access, while grace period settings balance security with user convenience. The passcode also protects FileVault encryption keys on macOS and enables data protection features on iOS, making it critical for overall device security.

Without enforced passcode policies, users often choose weak, easily guessable passwords like “1234” or reuse passwords across services. Compliance frameworks including NIST, CIS, and industry-specific standards require documented passcode policies and technical enforcement mechanisms.

Common Scenarios

Enterprise IT: Enforcing minimum 8-character alphanumeric passcodes with 15-minute lock screens on corporate devices accessing email, VPN, and cloud applications. IT adjusts policies based on device classification—executive devices may require stronger passcodes than general-purpose kiosks.

MSP: Implementing client-specific passcode policies that align with industry requirements. Healthcare clients may require 60-day password rotation while financial services clients enforce complex 10-character minimum requirements. MSPs document policy variations for compliance audits.

Education: Balancing security with usability by enforcing 6-digit numeric passcodes on student iPads while requiring more complex passcodes on faculty devices with access to student records. Schools typically use longer grace periods to reduce classroom disruption.

In Addigy

Addigy’s Passcode Policy configuration provides granular controls for length, character requirements, history, expiration, and grace periods. Addigy templates common policy configurations and validates settings to prevent impossible requirements. Admins can view passcode compliance status for each device and generate reports showing non-compliant devices.

When passcode policies change, Addigy provides user-facing notifications explaining new requirements and deadlines for compliance. Addigy tracks when users comply with updated policies and can escalate enforcement for devices that remain non-compliant after grace periods expire.

A device ownership designation indicating the device is owned by the end user rather than the organization, typically managed via User Enrollment.

What to Know

Personal ownership affects what management capabilities are available and what privacy expectations apply. Personal devices enrolled through User Enrollment maintain a separation between personal and work data, preventing IT from accessing personal apps, photos, or messages. Organizations must balance security needs with user privacy concerns, and the ownership designation determines which policies are enforceable and which would be considered overreach.

Common Scenarios

Enterprise IT: BYOD programs treat personal devices as partially managed — IT can enforce security requirements on corporate data (email, files, apps) without controlling the entire device. User Enrollment on iOS/iPadOS creates a managed partition that IT controls while leaving personal data untouched. Personal Macs typically require User-Approved MDM, which limits management scope compared to corporate-owned devices.

MSP: MSPs supporting clients with BYOD policies must clearly document what is and isn’t managed on personal devices. This includes educating users that the organization can wipe corporate data remotely but cannot access personal photos or browsing history. Liability and support boundaries should be explicit in service agreements.

Education: Schools rarely manage personal devices beyond guest Wi-Fi access or optional BYOD programs for older students. K-12 schools typically provide corporate-owned devices to ensure consistent management, avoid privacy concerns, and meet CIPA filtering requirements that are difficult to enforce on personal devices.

In Addigy

Addigy displays ownership type for enrolled devices and can apply different policy sets to personal vs. corporate-owned devices. Admins should configure Smart Groups to segment devices by ownership and deploy less intrusive policies to personal devices to respect privacy expectations while still protecting corporate data.

Allows sharing of cellular internet connection. Can be restricted via MDM to prevent unauthorized network access or control data usage.

What to Know

Personal Hotspot restrictions prevent users from tethering unauthorized devices to corporate cellular data plans, which can drive up data costs and create security risks by extending corporate network access to unmanaged devices. When employees enable Personal Hotspot, they may connect personal laptops, tablets, or family devices to the corporate data plan, consuming bandwidth intended for business use. Personal Hotspot also creates network security risks by allowing unmanaged devices to access network resources through the corporate-connected iPhone or iPad.

Common Scenarios

Enterprise IT: Corporate IT restricts Personal Hotspot on devices with limited or metered cellular plans to prevent data overage charges. For employees with unlimited corporate data plans, IT may allow Personal Hotspot as a convenience feature for legitimate business use (e.g., connecting a corporate laptop when WiFi is unavailable). IT typically restricts Personal Hotspot on shared devices like company phones used in retail or delivery roles where tethering serves no business purpose.

MSP: MSPs configure Personal Hotspot restrictions based on client cellular plans and data governance policies. Clients with per-device data caps typically restrict hotspot functionality to control costs, while clients with unlimited plans may allow it for employee convenience. MSPs should monitor cellular data usage after enabling hotspot to detect excessive personal use that drives up costs.

Education: Schools universally restrict Personal Hotspot on student devices to prevent students from tethering personal devices to school cellular plans, consuming bandwidth, or sharing internet access with unauthorized devices. Teacher devices may have Personal Hotspot enabled for field trip connectivity or classroom use cases where WiFi is unavailable.

In Addigy

Addigy’s Restrictions payload includes an “Allow Personal Hotspot” toggle that prevents devices from enabling Personal Hotspot when disabled. This restriction requires a supervised iOS/iPadOS device and applies immediately upon profile deployment. Disabling Personal Hotspot prevents users from turning on the feature in Settings and removes the Personal Hotspot toggle from Control Center. The restriction applies to cellular devices only—WiFi-only devices do not have hotspot functionality regardless of restriction settings.

PKCS is a group of public-key cryptography standards developed by RSA Security. In MDM environments, PKCS#12 (.p12) files are commonly used to distribute identity certificates to devices, while PKCS#7 is used for signing and encrypting data, including configuration profiles.

What to Know

PKCS standards provide interoperable formats for cryptographic operations essential to MDM security. PKCS#12 files bundle private keys and certificates into password-protected containers for secure distribution to devices, enabling client certificate authentication for network access (Wi-Fi, VPN) and application authentication. PKCS#7 (CMS) provides standard formats for signing and encrypting data, used by Apple to sign configuration profiles and verify profile integrity. Without standardized formats like PKCS, different systems would use incompatible certificate and key formats, preventing interoperability.

PKCS#1 (RSA cryptography), PKCS#8 (private key info), and PKCS#10 (certificate requests) are also commonly encountered in MDM certificate workflows. SCEP, used for automated certificate enrollment, relies on PKCS standards for certificate request and response formats. Understanding PKCS formats helps troubleshoot certificate deployment issues, as format mismatches or corrupted files cause enrollment and authentication failures.

Common Scenarios

Enterprise IT: IT teams export PKCS#12 files from certificate authorities to deploy identity certificates via MDM for 802.1X Wi-Fi authentication or VPN access. P12 files require passwords for protection, which must be securely communicated to MDM admins and properly configured in MDM payloads. IT must understand certificate-key pair relationships — PKCS#12 files contain both the certificate and private key, while PKCS#7 files typically contain only certificates. Profile signing using PKCS#7 ensures deployed profiles haven’t been tampered with during transit.

MSP: MSPs managing certificate-based authentication for clients must handle PKCS#12 file generation, secure password management, and deployment via MDM profiles. Client-specific certificate requirements may involve different CA formats and PKCS variations that MSPs must convert or adapt. MSPs should implement secure workflows for handling PKCS#12 files, as they contain sensitive private keys that could enable network access if compromised. Certificate renewal workflows require generating new PKCS#12 files and redeploying profiles before existing certificates expire.

Education: School districts deploying certificate-based Wi-Fi authentication use PKCS#12 files to distribute unique device certificates via MDM, enabling network access control and device tracking. Education IT must balance security (unique per-device certificates) with operational simplicity (shared certificates across device groups). PKCS#12 password management is challenging at scale — some schools use the device serial number or empty passwords, while others implement automated workflows that inject passwords programmatically during enrollment.

In Addigy

Addigy supports deploying PKCS#12 certificates through configuration profiles, allowing admins to upload P12 files with their passwords and deploy them to managed devices. Addigy securely stores certificate passwords and handles the deployment workflow, installing identity certificates into device keychains where they’re accessible to Wi-Fi, VPN, and application authentication systems. Administrators can specify certificate usage constraints, determining which services can access deployed certificates.

When configuring certificate profiles in Addigy, admins upload PKCS#12 files and provide passwords through the admin console. Addigy validates certificate format and expiration before deployment, helping catch configuration errors. Addigy’s certificate management features include expiration tracking and deployment status visibility, helping admins maintain certificate hygiene across the managed fleet and plan renewal activities before certificates expire.

Configuration settings defined in MDM that determine how devices will be enrolled and initially configured when going through Automated Device Enrollment (e.g., skipping Setup Assistant steps).

What to Know

Pre-stage enrollment configurations are essential for creating streamlined, consistent deployment experiences across ADE devices. By pre-defining which Setup Assistant screens to skip, which apps to install immediately, and which policies to enforce, IT can deliver devices that are ready for production use the moment users complete initial setup. Pre-stage configurations eliminate user confusion during enrollment, reduce setup time from hours to minutes, and ensure every device receives identical baseline configurations regardless of who sets it up or where they’re located.

Different device types, departments, or use cases often require different pre-stage configurations. A pre-stage for executive MacBooks might skip most Setup Assistant screens and pre-install productivity apps, while a pre-stage for shared iPads might enable Shared iPad mode and install educational apps. Well-designed pre-stage configurations are critical for zero-touch deployment, where devices ship directly to users without IT intervention.

Common Scenarios

Enterprise IT: Corporate IT creates pre-stage profiles for different employee roles. Sales MacBooks skip Setup Assistant screens for Siri and Apple ID, automatically install Microsoft Office and VPN clients, and enforce FileVault encryption. Finance iPads receive accounting apps and restrict app installation. Each pre-stage assigns devices to role-specific policies during enrollment, ensuring proper configurations without manual intervention.

MSP: MSPs configure client-specific pre-stage profiles in Apple Business Manager, each linked to the appropriate client’s MDM instance. When devices arrive for a new client deployment, the MSP assigns serial numbers to the correct pre-stage profile, ensuring devices automatically enroll to the right client account with client-appropriate branding, apps, and restrictions applied during setup.

Education: Schools create pre-stage profiles for different grade levels and device types. Elementary iPad pre-stages enable Shared iPad, skip Apple ID creation, and pre-install age-appropriate educational apps. High school MacBook pre-stages allow Apple ID but enforce restrictions on app installation. Each pre-stage ensures devices are classroom-ready immediately after Setup Assistant completes.

In Addigy

Addigy’s pre-stage enrollment configuration is accessed through the Automated Device Enrollment settings. You create pre-stage profiles that define Setup Assistant customization, authentication requirements, device naming conventions, and which policies apply during enrollment. When a device serial number is assigned to Addigy in Apple Business Manager, Addigy automatically applies the appropriate pre-stage profile based on your assignments.

Addigy allows multiple pre-stage profiles for different device scenarios, with granular control over Setup Assistant screens, mandatory authentication, await configuration behavior, and priority deployment policies. You can assign specific pre-stage profiles to device groups, ensuring consistent enrollment experiences while maintaining flexibility for different organizational units or device purposes.

Payload that manages TCC (Transparency, Consent, and Control) permissions on macOS. Pre-authorizes apps for access to protected resources like disk access, camera, or accessibility without user prompts.

What to Know

macOS requires explicit user consent before apps can access sensitive resources like the camera, microphone, contacts, or screen recording. While this protects user privacy, it creates friction for enterprise applications that require these permissions to function. The Privacy Preferences Policy Control (PPPC) payload allows IT to pre-approve necessary permissions for trusted enterprise software, eliminating disruptive prompts while maintaining security controls over which apps can access sensitive data.

Without PPPC pre-approvals, users face confusing permission dialogs that may be denied out of caution or misunderstanding, breaking critical business applications. PPPC also prevents users from accidentally granting permissions to malicious applications that request access using social engineering tactics.

Common Scenarios

Enterprise IT: Pre-approving screen recording permissions for remote support tools, microphone access for communication apps like Zoom, and full disk access for backup and security software. IT maintains an approved application list and regularly audits PPPC grants to ensure least-privilege access.

MSP: Deploying PPPC profiles for client-specific software including remote monitoring tools, specialized vertical applications, and accessibility software. MSPs document PPPC grants for security audits and compliance reviews, demonstrating controlled access to sensitive resources.

Education: Granting camera and microphone permissions for educational apps, accessibility features for students with disabilities, and screen recording for classroom management software. Schools must balance student privacy with necessary educational technology functionality.

In Addigy

Addigy’s PPPC configuration interface allows admins to select apps and specify which privacy permissions to grant. Addigy provides templates for commonly used enterprise applications and validates bundle identifiers and code signatures before deployment. Addigy’s PPPC builder includes options for Full Disk Access, Screen Recording, Accessibility, and all standard macOS privacy permissions.

When deploying applications that require PPPC, Addigy can bundle the privacy approval profile with the app installation to ensure seamless functionality. Addigy logs PPPC profile installation and provides troubleshooting guidance when applications still face permission issues after policy deployment.

An enrollment method where users manually install a configuration profile containing MDM enrollment settings. Typically results in unsupervised devices.

What to Know

Profile-based enrollment is synonymous with manual enrollment and represents the traditional method of enrolling devices that aren’t part of Automated Device Enrollment. Users download and install an enrollment profile, initiating the MDM enrollment process. This method is critical for BYOD scenarios, contractor devices, or any situation where devices weren’t purchased through Apple’s volume purchase programs. While convenient and flexible, profile-based enrollment cannot place devices under supervision, limiting available management features.

The enrollment profile contains all necessary MDM server information and trust certificates, but because it’s user-installed rather than automatically deployed, devices enrolled this way remain unsupervised. Users retain the ability to remove the MDM profile, ending management at any time. Organizations must clearly communicate expectations and policies around profile removal, especially in BYOD scenarios where personal device ownership intersects with corporate management needs.

Common Scenarios

Enterprise IT: Contractors and temporary employees receive enrollment links for their personal devices to access corporate resources. They download the enrollment profile from a web portal, install it, and gain access to company email, VPN, and internal apps. The profile enforces minimum security requirements like passcode complexity and encryption, but respects that the device is personally owned and limits invasive management.

MSP: When taking over management of an existing client with legacy devices not in Apple Business Manager, MSPs use profile-based enrollment to quickly establish management. The MSP sends enrollment links to all users, who install profiles on their existing devices. This allows immediate policy enforcement and app deployment while planning for eventual hardware refresh to ADE-capable devices.

Education: Faculty members with personal devices enroll via profile-based enrollment to access institutional Wi-Fi, email, and learning management systems. The enrollment profile installs necessary certificates and VPN configurations while maintaining clear boundaries between personal and institutional data. Faculty can remove the profile when they leave the institution or during summer break.

In Addigy

Addigy treats profile-based enrollment identically to manual enrollment—both terms refer to the same process. Users access Addigy’s enrollment portal through a provided URL, authenticate if required, and download an enrollment profile specific to their account. After installation, the device appears in Addigy with an unsupervised designation, and Addigy automatically limits available management actions to those compatible with unsupervised devices.

Addigy’s profile-based enrollment supports customization through enrollment policies that apply immediately after enrollment completes. You can configure authentication requirements, install Wi-Fi and VPN profiles during enrollment, and assign devices to specific policies based on user groups or device type, ensuring even manually enrolled devices receive appropriate baseline configurations.

A device state indicating the device has been enrolled in MDM and has received its initial configuration profiles, apps, and policies, making it ready for production use.

What to Know

The provisioned state represents the critical transition from a newly enrolled device to a production-ready workstation. Simply enrolling a device in MDM isn’t sufficient—provisioning ensures all necessary apps, security policies, certificates, VPN configurations, and restrictions are installed and active before users begin work. A properly provisioned device has everything needed for employees to be productive immediately, from productivity apps and security agents to Wi-Fi credentials and identity certificates. Incomplete provisioning leads to support tickets, productivity delays, and security gaps.

Organizations establish provisioning standards that define what “fully provisioned” means for different device types or user roles. Executive MacBooks might require VPN, Microsoft Office, and specific security tools, while sales iPads need CRM apps and customer-facing presentation software. Tracking provisioned state helps IT verify deployments completed successfully and identify devices stuck in partially configured states requiring intervention.

Common Scenarios

Enterprise IT: IT uses provisioned state to track new device deployments. After enrollment completes, IT monitors provisioning progress as devices download priority policies, install required apps, and apply security configurations. Once all critical items install successfully, IT marks devices as provisioned and hands them to users. Devices not reaching provisioned state within expected timeframes trigger alerts for investigation.

MSP: MSPs define client-specific provisioning checklists—VPN profiles, security agents, productivity apps, and client-specific tools. As devices enroll, the MSP tracks provisioning completion across the fleet, ensuring all deployed devices meet the client’s baseline requirements. The MSP reports provisioning metrics to clients, showing how many devices are fully deployed versus pending configuration.

Education: Schools provision student iPads with educational apps, classroom management tools, and grade-appropriate restrictions before distributing them. The provisioned state confirms each iPad has the full educational software suite installed. During mass deployments of 1:1 devices, IT tracks what percentage of devices are fully provisioned and ready for distribution versus still downloading required apps.

In Addigy

Addigy doesn’t have an explicit “provisioned” flag, but you can determine provisioning state through device facts, policy compliance, and app installation status. After enrollment, Addigy applies priority deployments and policies, which you can track through compliance dashboards. Create smart groups based on policy compliance and required app installation to identify fully provisioned devices versus those still pending configuration.

Addigy’s await configuration option in ADE enrollment prevents devices from completing Setup Assistant until priority policies install, ensuring devices are essentially provisioned before users access them. You can also use custom facts or Addigy Catalog app installation status to track provisioning milestones, creating reports that show which devices have completed your organization’s provisioning checklist.

A state where an iOS or iPadOS device connects to iTunes/Finder for restoration when the device cannot boot normally. Less invasive than DFU mode.

What to Know

Recovery Mode provides a standard method for restoring iOS and iPads experiencing boot failures or severe software corruption without resorting to the deeper DFU Mode. It allows devices to communicate with iTunes/Finder or Apple Configurator for firmware updates and system restoration while maintaining some boot loader functionality. Recovery Mode is the appropriate first attempt at device recovery before escalating to DFU Mode, and can resolve most software-related boot failures.

Common Scenarios

Enterprise IT: Corporate IT guides users through Recovery Mode restoration when company iPhones won’t boot after failed updates or configuration issues. This restores devices to working condition while maintaining the ability to restore from backup, minimizing data loss and user disruption.

MSP: MSPs use Recovery Mode to restore client iPhones experiencing boot loops or update failures. It’s the standard recovery method that resolves most issues without requiring the more aggressive DFU Mode approach.

Education: School IT uses Recovery Mode to restore student iPads that won’t boot after failed updates or student tampering. This recovers devices quickly without the complexity of DFU Mode procedures.

In Addigy

While Recovery Mode operates outside MDM, devices enrolled in Automated Device Enrollment automatically re-enter Addigy’s enrollment after Recovery Mode restoration completes. Addigy’s Return to Service then ensures devices receive all policies and apps automatically.

The process of installing macOS over an existing installation or on an erased drive, available through macOS Recovery. Can resolve system file corruption.

What to Know

Reinstall macOS resolves persistent software corruption, damaged system files, and failed updates without requiring full data wipes or user migration. This is critical when macOS exhibits crashes, boot failures, or application errors that survive standard troubleshooting, but user data remains intact and accessible. Reinstalling the OS over itself replaces all system files while preserving user accounts, applications, and documents, minimizing disruption and avoiding lengthy backup and restore processes.

Common Scenarios

Enterprise IT: Corporate IT guides users through macOS reinstalls when system corruption causes repeated crashes or prevents software updates, but user data is still accessible. This avoids full wipes that would require backup validation and restore time, getting users back to productivity faster.

MSP: MSPs use macOS reinstall to resolve client Mac issues caused by corrupted system files or failed updates without erasing user data. This preserves client applications and settings while fixing underlying OS problems, reducing client disruption and billable restore time.

Education: School IT reinstalls macOS on faculty Macs experiencing persistent issues while preserving their classroom resources, lesson plans, and applications. This maintains teacher productivity without requiring full device reimaging during the school year.

In Addigy

While macOS reinstall happens locally via Recovery Mode, devices enrolled in ADE remain under Addigy management after the reinstall completes. Addigy automatically reapplies all MDM profiles, policies, and apps, ensuring the device returns to compliance without manual IT reconfiguration.

An MDM capability to remotely lock a device and optionally display a custom message, preventing unauthorized access while the device is lost or pending administrative action.

What to Know

Remote Lock provides immediate security response when devices are lost, stolen, or in the possession of unauthorized users. Unlike waiting for users to manually lock their devices or hoping passwords prevent access, Remote Lock ensures devices are immediately secured regardless of user action or cooperation. The ability to display custom messages transforms locked devices into recovery tools by showing contact information for device return, significantly improving recovery rates.

Common Scenarios

Enterprise IT: Corporate IT issues Remote Lock commands immediately when employees report lost or stolen devices, preventing unauthorized access to corporate email, files, and applications. The lock screen message displays IT contact information to facilitate device return.

MSP: MSPs use Remote Lock to secure client devices when employees are terminated or devices are reported missing. This ensures client data remains protected while recovery attempts are made, and provides documentation of security response for compliance purposes.

Education: Schools use Remote Lock on student iPads and MacBooks reported missing or stolen, displaying the school IT contact number to encourage device return. Combined with location tracking in Lost Mode, this helps recover valuable educational technology.

In Addigy

Addigy supports Remote Lock through device actions, allowing admins to lock devices and set custom lock screen messages with a single click. The lock is enforced immediately on devices with network connectivity, and is queued for offline devices to execute once they reconnect.

The ability to remotely erase all data from a device to protect organizational information when devices are lost, stolen, or decommissioned.

What to Know

Remote Wipe provides critical security response capability when devices containing sensitive data are lost, stolen, or in unauthorized possession. Unlike hoping devices remain locked or data stays encrypted, Remote Wipe ensures complete data destruction regardless of physical device control. This is essential for compliance with data breach notification laws, protecting corporate secrets, and ensuring terminated employees can’t access organizational data even if they refuse to return company devices.

Common Scenarios

Enterprise IT: Corporate IT executes Remote Wipe on lost or stolen devices to protect sensitive corporate data, comply with breach notification requirements, and ensure competitive information doesn’t fall into unauthorized hands. This is especially critical for executive devices containing strategic business information.

MSP: MSPs use Remote Wipe to sanitize client devices during employee terminations, device reassignments, or security incidents. This provides clients with documented proof of data destruction for compliance audits and reduces liability from compromised devices.

Education: Schools issue Remote Wipe on lost or stolen student devices to protect student personal information and comply with data protection regulations like FERPA. This ensures student data privacy even when physical devices can’t be recovered.

In Addigy

Addigy supports Remote Wipe via the MDM Erase Device command, enabling admins to securely wipe devices remotely. When combined with Automated Device Enrollment, wiped devices automatically re-enroll in Addigy after the wipe completes, allowing recovered devices to be quickly redeployed without manual configuration.

REST is an architectural style for designing networked applications. In MDM environments, RESTful APIs are ubiquitous for programmatic management of devices, users, policies, and configurations. Modern MDM servers expose REST APIs to allow for automation and integration with third-party tools.

What to Know

RESTful APIs enable programmatic access to MDM functionality, allowing organizations to automate device provisioning, generate custom reports, integrate with external systems, and build custom workflows that extend platform capabilities. REST’s simplicity (standard HTTP methods GET/POST/PUT/DELETE) and stateless nature make it easier to understand and implement than complex protocols like SOAP. Modern IT automation relies heavily on REST APIs for orchestrating actions across multiple systems — provisioning devices when users are hired, synchronizing device assignments from HR systems, or triggering alerts based on compliance events.

REST APIs also enable ecosystem integration, allowing MDM platforms to communicate with ticketing systems, asset management databases, identity providers, and security tools. API-driven management supports infrastructure-as-code practices where device policies and configurations are defined in version-controlled code repositories rather than manually configured through web interfaces. This improves consistency, enables peer review of changes, and supports disaster recovery through automated rebuilds.

Common Scenarios

Enterprise IT: IT teams leverage MDM REST APIs to automate device provisioning triggered by HR onboarding workflows, generate compliance reports for auditors, and synchronize device assignments with Active Directory group memberships. Custom scripts query device inventories for security analysis, identifying devices with outdated OS versions or missing security configurations. API integrations with ITSM platforms enable automated ticket creation when devices fall out of compliance or require administrative attention. IT must secure API credentials and implement rate limiting to prevent abuse.

MSP: MSPs build multi-tenant management dashboards that aggregate device data across client accounts via REST APIs, providing unified visibility and standardized reporting. API-driven automation enables MSPs to implement consistent onboarding workflows, automated patch management, and compliance monitoring across diverse client environments. MSPs should implement error handling and retry logic in API integrations to handle transient failures gracefully. API usage tracking helps MSPs understand which clients consume most platform resources and inform capacity planning.

Education: School districts use REST APIs to synchronize student rosters from SIS to MDM, automating device assignments at the start of each school year and updating assignments when students change schools or graduate. API integrations enable education IT to generate asset reports for budget planning and automate device decommissioning workflows. Custom reporting scripts query API endpoints to generate board reports showing technology utilization metrics and device inventory status.

In Addigy

Addigy provides comprehensive REST APIs that enable programmatic access to all platform functionality, from device management and policy deployment to user provisioning and reporting. The API follows REST conventions with JSON payloads, standard HTTP status codes, and clear endpoint documentation. Administrators generate API credentials through the Addigy console and use them to authenticate requests, with role-based permissions controlling what API actions each credential can perform.

Addigy’s API documentation includes interactive examples, sample code in multiple languages, and detailed descriptions of request/response formats for every endpoint. Addigy supports webhook notifications that push event data to external systems, complementing the pull-based REST API with real-time push notifications. Organizations building custom integrations can leverage Addigy’s API to create tailored workflows, reporting dashboards, and automation that extends platform capabilities beyond the standard web interface.

Payload that enforces policies and restrictions on device capabilities (e.g., camera, App Store, iCloud, USB accessories). Can be layered additively.

What to Know

Restrictions payloads provide granular control over device functionality, allowing organizations to enforce security policies, prevent data leakage, ensure compliance, and create focused user experiences. By disabling unnecessary features, IT reduces attack surface area, prevents shadow IT, and ensures devices are configured appropriately for their intended purpose. Restrictions are essential for creating compliant, secure, and purpose-built devices across diverse use cases.

Without restrictions, users can install unapproved software, share corporate data through personal cloud services, use cameras in secure facilities, or access entertainment features during work hours. Many compliance frameworks require documented technical controls that prevent users from bypassing security policies, which restrictions payloads directly enable.

Common Scenarios

Enterprise IT: Disabling iCloud backup to prevent corporate data from leaving managed environments, blocking camera usage in secure facilities, preventing users from removing MDM profiles, and restricting App Store access to only company-approved applications. IT tailors restrictions based on user roles and device purposes.

MSP: Implementing client-specific restriction policies that align with industry regulations and corporate policies. MSPs document restriction configurations for compliance audits and adjust policies as client requirements evolve or new threats emerge.

Education: Creating focused learning environments by disabling gaming features, restricting app installations, preventing students from removing profiles, and blocking inappropriate content. Schools often implement age-appropriate restrictions that vary between elementary, middle, and high school devices.

In Addigy

Addigy organizes restriction options into logical categories including App Store controls, iCloud restrictions, device functionality, and content filtering. Addigy clearly indicates which restrictions require supervision and provides descriptions for each setting to prevent misconfiguration. Admins can clone and modify restriction profiles for different user groups or device types.

When viewing restriction profiles in Addigy, admins see a summary of enabled restrictions and can preview how settings will affect end users. Addigy validates restriction combinations to prevent conflicts and warns when restrictions might interfere with other deployed policies or required functionality.

An MDM feature that preserves device enrollment through an erase operation, allowing devices to automatically re-enroll in the same MDM configuration after being wiped.

What to Know

Return to Service eliminates the time-consuming manual reconfiguration process after devices are erased, repaired, or returned from users. Instead of requiring IT staff to manually re-enroll devices, install profiles, and configure settings, Return to Service automatically initiates MDM enrollment and applies all policies as soon as the device completes initial setup. This transforms device recovery and redeployment from a multi-hour manual process into an automated workflow, dramatically reducing IT workload and device downtime.

Common Scenarios

Enterprise IT: Corporate IT uses Return to Service when redeploying devices to new employees after the previous user’s data has been erased. Devices automatically re-enroll during setup, receiving all corporate policies, apps, and configurations without IT intervention, enabling same-day redeployment.

MSP: MSPs leverage Return to Service to quickly redeploy client devices after repairs, replacements, or reassignments. This reduces billable hours spent on manual device configuration and improves client satisfaction through faster device turnaround times.

Education: Schools use Return to Service between semesters to rapidly wipe and redeploy student devices. After erasing hundreds of iPads, Return to Service ensures each device automatically re-enrolls and receives classroom apps and restrictions without individual IT attention.

In Addigy

Addigy’s Return to Service integration works seamlessly with Automated Device Enrollment (ADE). After erasing an ADE-enrolled device, simply connecting to Wi-Fi during setup triggers automatic enrollment in Addigy, and the device receives all assigned profiles, apps, and configurations based on its group membership without manual intervention.

Apple Configurator 2’s advanced recovery features for iOS and iPads. ‘Revive’ updates firmware without erasing data, while ‘Restore’ performs a complete erase and reinstallation.

What to Know

Revive and Restore provide critical recovery options for iOS and iPads that won’t boot or are stuck in recovery mode. Revive updates device firmware without erasing user data, while Restore performs a complete wipe and firmware update. These functions can recover devices that Finder or iTunes cannot restore, and are essential for fixing devices with corrupted firmware or failed iOS updates. For organizations managing iOS device fleets, these tools prevent costly device replacements when software recovery is possible.

Common Scenarios

Enterprise IT: Corporate IT uses Revive to attempt data-preserving firmware recovery on company iPhones experiencing boot failures, resorting to Restore only when Revive fails. This minimizes data loss and user disruption when recovering failed devices.

MSP: MSPs use Apple Configurator Revive and Restore to recover client iPhones that fail during updates or become stuck in boot loops. Successfully recovering devices without Apple Store visits saves clients time and maintains service level agreements.

Education: School IT uses Revive and Restore to recover student iPads experiencing boot failures after failed updates or student tampering. This keeps devices in classroom circulation rather than sending them for depot repair.

In Addigy

While Revive and Restore operate outside MDM, devices enrolled in Automated Device Enrollment automatically re-enter Addigy’s enrollment flow after the restore completes. Addigy’s Return to Service then ensures devices are immediately configured with all policies and apps without manual IT intervention.

A special macOS startup mode that loads only essential system extensions and performs directory checks, used for troubleshooting software conflicts and startup issues.

What to Know

Safe Mode helps isolate whether Mac issues are caused by third-party software, damaged caches, or corrupted system files. By loading only Apple software and performing automatic directory repairs, Safe Mode enables Macs with severe software issues to boot successfully and allows IT to identify problematic extensions or apps. This diagnostic capability is essential for troubleshooting kernel panics, boot failures, and persistent crashes without immediately resorting to full OS reinstalls.

Common Scenarios

Enterprise IT: Corporate IT guides users through Safe Mode when Macs won’t boot normally or exhibit persistent crashes. If the Mac works correctly in Safe Mode, IT knows the issue involves third-party software or startup items that can be removed without full OS reinstall.

MSP: MSPs use Safe Mode to diagnose client Mac boot and stability issues remotely, determining if problems stem from third-party software versus system corruption. This helps scope repair work and avoid unnecessary full wipes when removing problematic software will suffice.

Education: School IT boots lab Macs into Safe Mode when they exhibit startup issues or persistent crashes, using it as a diagnostic tool to determine if the problem is caused by problematic student-installed apps or actual system corruption requiring reimaging.

In Addigy

While Safe Mode disables many third-party processes including some MDM functions, Addigy admins can instruct users to boot into Safe Mode for troubleshooting and then restart normally. Once back in normal mode, Addigy management resumes and any pending policies or apps are applied.

SAML is an XML-based open standard for exchanging authentication and authorization data between parties. In MDM environments, SAML enables enterprise SSO for MDM administrator consoles and user portals, allowing organizations to use existing identity infrastructure (like Okta or Azure AD).

What to Know

SAML enables single sign-on across enterprise applications, allowing users to authenticate once with their identity provider and access multiple applications without re-entering credentials. For MDM platforms, SAML integration eliminates separate MDM passwords for admins, reducing credential management overhead and enabling consistent enforcement of authentication policies (MFA, password complexity, session timeouts) defined at the identity provider level. SAML assertions carry identity and authorization information cryptographically signed by the identity provider, preventing tampering and enabling trust across organizational boundaries.

SAML is particularly important for enterprises with established identity infrastructure and multiple SaaS applications. Rather than managing passwords in every application, IT maintains a single source of truth in the identity provider. User lifecycle management is simplified — when employees leave, disabling their account in the identity provider immediately revokes access to all SAML-connected applications. SAML also enables just-in-time provisioning where user accounts are created automatically upon first login, reducing onboarding friction.

Common Scenarios

Enterprise IT: Corporate IT integrates MDM with Azure AD or Okta using SAML to enable SSO for MDM admins, eliminating separate MDM credentials and enabling consistent MFA enforcement. IT configures SAML by registering the MDM platform in the identity provider, exchanging metadata files that define endpoints and certificates, and mapping SAML attributes to MDM user roles. SAML attribute-based access control allows IT to grant different MDM permissions based on Active Directory groups or Okta groups embedded in SAML assertions. Session timeout policies defined in the identity provider automatically apply to MDM console sessions.

MSP: MSPs use SAML to enable technicians to access multiple client MDM instances through federated authentication, eliminating per-client credential management. SAML enables just-in-time provisioning where technician accounts are created automatically when first accessing a client MDM instance. MSPs should implement SAML best practices including certificate rotation schedules, proper attribute mapping, and logout propagation to ensure sessions terminate properly. SAML metadata updates when renewing certificates require coordination across all integrated applications to prevent authentication failures.

Education: School districts integrate MDM with Google Workspace or Microsoft 365 using SAML, allowing IT staff to authenticate to MDM consoles using school credentials. SAML simplifies administrator lifecycle management — when staff change roles or leave the district, access changes in the identity provider automatically affect MDM permissions. Educational SAML configurations must carefully map attributes to avoid inadvertently granting excessive permissions based on broadly-scoped directory groups.

In Addigy

Addigy supports SAML 2.0 integration for administrator single sign-on, enabling organizations to integrate with SAML-compliant identity providers like Okta, Azure AD, OneLogin, and others. Administrators configure SAML by exchanging metadata between Addigy and their identity provider, establishing the trust relationship and endpoint configurations. Addigy supports SAML attribute mapping for user identification and role assignment based on identity provider groups.

Addigy’s SAML configuration wizard guides admins through the setup process, providing clear documentation and troubleshooting guidance. Addigy validates SAML assertions and handles session management automatically, abstracting protocol complexity while maintaining security best practices. Organizations can enforce MFA and other authentication policies at the identity provider level, with those policies automatically applying to Addigy console access through SAML integration. Addigy support can assist with SAML troubleshooting including assertion analysis and attribute mapping verification.

SCEP is a protocol for issuing and renewing digital certificates through a standardized, automated process. In MDM implementations, SCEP is essential for automated certificate deployment, allowing devices to automatically request certificates for Wi-Fi, VPN, and identity verification during enrollment.

What to Know

SCEP automates certificate issuance at scale, eliminating manual certificate generation and distribution workflows that don’t scale beyond small deployments. During device enrollment, MDM can automatically trigger SCEP certificate requests, with devices generating key pairs and submitting certificate signing requests (CSRs) to the CA via SCEP. The CA validates requests (often using challenge passwords or existing MDM enrollment certificates) and issues certificates that devices automatically install. This enables zero-touch certificate deployment for 802.1X network authentication, VPN access, and application authentication without admins ever handling individual certificates.

SCEP also supports automated certificate renewal, with devices detecting approaching expiration and requesting new certificates before existing ones expire. This prevents certificate expiration outages that break network connectivity and VPN access. SCEP’s standardized protocol enables interoperability between different CAs and MDM platforms, avoiding vendor lock-in. Without SCEP, organizations must manually generate, distribute, and install certificates on every device — an error-prone process that doesn’t scale to fleets of hundreds or thousands of devices.

Common Scenarios

Enterprise IT: Corporate deployments use SCEP to issue unique device certificates during ADE enrollment, with certificates used for 802.1X Wi-Fi authentication and VPN access. IT configures SCEP profiles in MDM that specify the CA URL, challenge password (or use MDM certificate for authentication), and certificate attributes (key size, subject name template). SCEP enables per-device certificates that identify individual devices on the network, supporting network access control policies and device tracking. IT must maintain SCEP CA infrastructure and ensure MDM servers can reach SCEP endpoints during enrollment workflows.

MSP: MSPs leverage SCEP to automate certificate deployment across client devices, reducing operational overhead compared to manual certificate distribution. Client-specific SCEP configurations may integrate with different CA infrastructures (Microsoft CA, third-party CAs, cloud-based CAs). MSPs should implement SCEP monitoring to detect enrollment failures caused by CA outages, misconfigured challenge passwords, or network connectivity issues. SCEP certificate templates must be carefully configured to generate certificates with appropriate validity periods, key usage constraints, and subject names that meet client security policies.

Education: School districts deploy SCEP-issued certificates to student and staff devices for 802.1X Wi-Fi authentication, enabling network access control and device tracking. SCEP automation is essential for managing large student device deployments where manual certificate distribution would be impractical. Education IT must coordinate SCEP configuration with network infrastructure teams managing RADIUS servers that validate certificates during 802.1X authentication. SCEP certificate validity periods should align with device refresh cycles to avoid mid-year certificate expiration that disrupts network access during the school year.

In Addigy

Addigy supports SCEP certificate enrollment through configuration profiles, allowing admins to configure SCEP CA endpoints, authentication methods, and certificate parameters. Devices automatically request certificates via SCEP during profile installation, with certificates installed into device keychains for use by Wi-Fi, VPN, and other authentication systems. Administrators configure SCEP profiles by specifying the CA URL, subject name template, key size, and authentication credentials (challenge password or certificate-based authentication).

Addigy’s SCEP implementation follows Apple’s SCEP payload specifications, supporting standard SCEP features including certificate renewal and multiple certificate requests per profile. Addigy provides visibility into certificate deployment status, helping admins identify devices where SCEP enrollment failed due to network issues, CA problems, or configuration errors. When troubleshooting SCEP failures, Addigy support can analyze device logs to identify specific error conditions and recommend configuration adjustments.

Payload that enables automatic certificate enrollment and renewal via SCEP protocol. Essential for scaling certificate-based authentication for Wi-Fi and VPN.

What to Know

SCEP payloads enable automated certificate provisioning and renewal, eliminating manual certificate distribution and reducing the risk of expired certificates disrupting services. Certificates are essential for authenticating devices to Wi-Fi networks, VPNs, and internal services, and SCEP ensures each device receives unique identity certificates without IT intervention. Automated certificate management reduces operational overhead, prevents service disruptions from expired certificates, and enables certificate-based authentication at scale.

Manual certificate distribution creates security risks including certificate sharing, insecure storage, and delayed renewals. SCEP provides a standardized, secure method for certificate lifecycle management that aligns with PKI best practices and compliance requirements.

Common Scenarios

Enterprise IT: Provisioning unique device certificates for 802.1X wireless authentication, VPN access, and S/MIME email signing. IT configures SCEP to automatically renew certificates before expiration, preventing authentication failures and maintaining continuous connectivity to enterprise resources.

MSP: Managing certificate deployment for multiple client PKI environments, each with different certificate authorities and authentication requirements. MSPs use SCEP to streamline onboarding and reduce support tickets related to certificate expiration and manual renewal processes.

Education: Deploying certificates for secure Wi-Fi access across student and faculty devices. Schools leverage SCEP to provision certificates tied to user identities, enabling network access logging and accountability while simplifying authentication infrastructure.

In Addigy

Addigy’s SCEP payload configuration allows admins to specify CA URLs, certificate templates, key sizes, and renewal parameters. Addigy supports integration with common enterprise certificate authorities including Microsoft CA, OpenSSL-based systems, and cloud PKI providers. Addigy logs certificate enrollment success and failures, providing visibility into certificate deployment status across the fleet.

When certificates approach expiration, Addigy can trigger automated renewal processes and alert admins to enrollment failures requiring attention. Addigy displays certificate expiration dates for each device, enabling proactive certificate lifecycle management and preventing service disruptions.

MDM command to schedule download/install of OS updates. Can force updates on supervised devices.

What to Know

ScheduleOSUpdate enables proactive patch management by allowing IT to remotely trigger OS updates across the fleet, ensuring devices receive critical security patches and feature updates on a predictable timeline. Without this capability, organizations must rely on users to manually initiate updates — a process that is frequently deferred, forgotten, or avoided, leaving devices vulnerable to known exploits. Automated OS update management is essential for maintaining security compliance and meeting audit requirements that mandate timely patching.

For supervised devices, ScheduleOSUpdate can force installation even if users attempt to defer or cancel updates, ensuring critical security patches are applied regardless of user behavior. This is particularly important for “zero-day” vulnerabilities where delays in patching create immediate organizational risk. The command also supports sophisticated scheduling scenarios like enforcing updates during maintenance windows, ensuring devices download updates over Wi-Fi before cellular installation, or staggering rollouts to avoid disrupting all users simultaneously.

Common Scenarios

Enterprise IT: Schedule quarterly OS updates to maintain supported versions across the fleet, targeting updates during maintenance windows (overnight, weekends) to minimize user disruption. Force immediate security updates on supervised devices when critical vulnerabilities are disclosed (e.g., zero-day exploits), ensuring the fleet is patched before attackers can weaponize the vulnerability. Stage updates by department, updating IT staff first to validate stability before rolling out to production users.

MSP: Coordinate OS update schedules with client maintenance windows to avoid disrupting business-critical operations. For clients with strict uptime requirements (retail, healthcare), schedule updates during known low-activity periods and provide rollback plans. Use phased rollout strategies where updates are initially deployed to a pilot group of devices per client, then expanded to the full fleet after confirming stability.

Education: Schedule OS updates for student devices during extended breaks (summer, winter holidays) when devices aren’t in active classroom use. For staff devices, coordinate update schedules with the academic calendar to avoid disrupting critical periods like standardized testing, report card deadlines, or enrollment windows. Use supervised mode enforcement to ensure student devices receive required updates before being issued for the new school year.

In Addigy

Addigy supports ScheduleOSUpdate through both the traditional MDM command (for older devices) and the modern Declarative Device Management (DDM) protocol for compatible macOS and iOS versions. Admins configure update policies through Addigy’s System Updates interface, specifying target OS versions, enforcement deadlines, and installation windows. Addigy automatically issues the appropriate command type based on device capabilities and tracks update compliance across the fleet. Addigy also provides reporting on update status, deferral counts, and compliance exceptions, allowing IT to identify devices that are out of compliance or have repeatedly deferred updates beyond acceptable thresholds.

Ensures only trusted operating system software loads during startup. On Apple Silicon, policies like ‘Full Security’ or ‘Reduced Security’ can be managed.

What to Know

Secure Boot prevents malware from infecting the boot process, ensuring that only Apple-signed operating system code can run during startup. This protects against bootkits and rootkits that attempt to compromise the system before security tools can load. On Apple Silicon Macs, Secure Boot policies determine what software is allowed to boot: Full Security (only current signed OS), Reduced Security (older or developer-signed OS), and Permissive Security (no signature enforcement).

For enterprises, Secure Boot settings impact compatibility with legacy boot management tools, netboot solutions, and alternative operating systems. While Full Security provides maximum protection, some organizations need Reduced Security to support specific workflows. MDM can remotely configure Secure Boot policies on Apple Silicon, eliminating the need for local administrator intervention in Startup Security Utility.

Common Scenarios

Enterprise IT: Corporate Macs are typically configured for Full Security to maintain maximum boot protection. When deploying kernel extensions or system extensions that require specific signing, IT may temporarily adjust Secure Boot settings via MDM, then restore Full Security once deployment completes.

MSP: Most managed clients use default Full Security settings, but clients with specialized requirements (virtualization, development, legacy tools) may need Reduced Security. MSPs document these exceptions and ensure clients understand the security trade-offs involved in weakening boot protection.

Education: Schools maintain Full Security on all student and staff devices to prevent unauthorized OS installations or boot modifications. This prevents students from attempting to boot from external drives or install unauthorized operating systems that would bypass school content filtering.

In Addigy

Addigy can deploy configuration profiles to remotely manage Secure Boot settings on Apple Silicon Macs, eliminating the need for users to access Startup Security Utility. Admins can view current Secure Boot status in device inventory and deploy policies that enforce Full Security across the fleet. For devices that require Reduced Security, Addigy tracks these exceptions and can report on policy compliance.

Dedicated hardware coprocessor for cryptographic operations (Touch ID, Face ID, Data Protection keys). Operates independently of the main OS for maximum security.

What to Know

The Secure Enclave is a hardware-isolated security processor that stores and protects the most sensitive cryptographic operations on Apple devices. It manages biometric authentication (Touch ID/Face ID), encryption keys for Data Protection, and secure boot verification. Because it operates independently from the main processor and operating system, even if the main OS is compromised, the Secure Enclave remains protected and cannot be accessed or manipulated by malicious software.

For enterprise security, the Secure Enclave provides hardware-backed protection for credential storage, passcode attempts, and cryptographic keys. It enforces rate limiting on passcode attempts, making brute-force attacks impractical, and ensures that encryption keys never leave the secure hardware boundary. This hardware root of trust is fundamental to Apple’s data protection architecture and is required for features like FileVault, Secure Boot, and biometric authentication.

Common Scenarios

Enterprise IT: The Secure Enclave protects corporate data by ensuring FileVault encryption keys and biometric authentication data cannot be extracted, even with physical device access. IT relies on this hardware protection to meet data security requirements for regulated industries and high-security environments.

MSP: When advising clients on device security policies, MSPs leverage the Secure Enclave’s protections to demonstrate hardware-backed security guarantees. This is particularly important for clients in healthcare, finance, or legal sectors where data protection regulations demand tamper-resistant cryptographic key storage.

Education: While students and teachers may not interact directly with the Secure Enclave, its protection of biometric data and device encryption ensures that school-managed devices meet privacy standards for protecting student information and comply with data protection regulations like FERPA and COPPA.

In Addigy

Addigy does not directly manage the Secure Enclave (it’s a hardware component), but admins can view device inventory information that indicates Secure Enclave presence and capabilities. When deploying FileVault, biometric authentication policies, or passcode requirements through Addigy, these configurations leverage Secure Enclave protection automatically on supported devices. Addigy’s reporting helps identify devices with or without Secure Enclave support, which may impact security policy decisions for older hardware.

The series of configuration screens presented when a device is first powered on or after being erased. ADE allows MDM to customize these screens.

What to Know

Setup Assistant is the user’s first experience with a new or freshly erased Apple device, guiding them through essential configuration like language, Wi-Fi, Apple ID, and privacy settings. For organizations deploying devices, Setup Assistant presents both an opportunity and a challenge. Without control over Setup Assistant, users must manually navigate numerous screens, many irrelevant to corporate deployments, wasting time and potentially making configuration mistakes. With Automated Device Enrollment, organizations can customize Setup Assistant to skip unnecessary screens, enforce specific configurations, and streamline the initial setup experience.

The Setup Assistant customization capabilities available through ADE are fundamental to zero-touch deployment. By pre-configuring which screens users see, organizations reduce setup time from 30+ minutes to under 5 minutes. Skipping screens like Apple Pay, Siri, and Screen Time setup eliminates user confusion and ensures consistent device configurations across the fleet. Setup Assistant customization also enables mandatory MDM enrollment—ADE can prevent users from completing setup without enrolling, ensuring no device enters production unmanaged.

Common Scenarios

Enterprise IT: Corporate MacBooks are pre-configured to skip Setup Assistant screens for Apple ID, Siri, Touch ID, and iCloud. Users only see language, keyboard, and local account creation screens, reducing setup time and preventing accidental personal Apple ID association. The simplified Setup Assistant enables remote employees to unbox and configure devices without IT assistance, while mandatory MDM enrollment ensures devices don’t proceed to desktop without proper management.

MSP: MSPs configure client-specific Setup Assistant customizations in pre-stage profiles. For executive deployments, Setup Assistant skips most screens and pre-fills organization information. For general staff, Setup Assistant allows some personalization while skipping complex privacy and service enrollment screens. The MSP tests Setup Assistant flows before mass deployments to ensure user experience matches client expectations and deployment timelines.

Education: School iPads have Setup Assistant configured to skip all non-essential screens for student deployments. Apple ID creation is skipped for shared devices, while 1:1 student devices prompt for Managed Apple ID authentication. Diagnostic data sharing screens are pre-configured per school policy. The streamlined Setup Assistant allows students to begin using devices immediately after powering on, without teacher intervention or IT support.

In Addigy

Addigy’s Automated Device Enrollment configuration includes Setup Assistant customization options available through pre-stage profiles. You specify which Setup Assistant screens to display or skip, including language, Apple ID, biometrics, diagnostics, and more. Addigy’s pre-stage editor provides a clear interface for enabling or disabling each Setup Assistant pane, with descriptions of what each screen does and recommendations for corporate deployments.

When devices enrolled through Addigy’s ADE integration power on, they automatically apply your configured Setup Assistant customizations before presenting any screens to users. Addigy also supports await configuration, which displays a configuration progress screen during Setup Assistant while policies and apps install, ensuring devices are fully provisioned before users reach the desktop. You can create multiple pre-stage profiles with different Setup Assistant customizations for different device types or organizational units.

Allows multiple users to sign in to a single iPad with Managed Apple IDs, maintaining individual data and settings. Primarily for education and business shift environments.

What to Know

Shared iPad solves the multi-user access challenge for organizations that need multiple users to share a single device while maintaining personalized experiences and data separation. In education, Shared iPad allows schools to deploy one iPad per three students rather than one-to-one, significantly reducing hardware costs while still providing students with personalized apps, files, and settings. In business environments, Shared iPad enables shift workers in retail, healthcare, or hospitality to share devices without commingling personal data or requiring complex manual account switching.

Shared iPad requires Managed Apple IDs (created through ABM/ASM), supervised devices, and 32GB+ storage. It leverages iCloud to sync user data across sessions, so students or employees can log in to any Shared iPad and access their personalized environment. This approach combines the cost efficiency of shared devices with the personalization benefits of one-to-one deployments.

Common Scenarios

Enterprise IT: Corporate IT deploys Shared iPad for shift workers in retail stores, hospital nursing stations, or warehouse environments where employees need access to corporate apps and data but don’t require dedicated devices. Each employee logs in with their Managed Apple ID, accesses their personalized workspace, and logs out at shift end. Shared iPad reduces hardware costs while maintaining data separation and audit trails for user activity.

MSP: MSPs configure Shared iPad for clients with shift-based workforces or shared device deployments. Setup requires creating Managed Apple IDs for each user, configuring MDM settings for Shared iPad mode, and ensuring adequate iCloud storage for user data syncing. MSPs should educate clients about the 32GB minimum storage requirement and the need for reliable WiFi for user session syncing.

Education: Schools deploy Shared iPad to maximize iPad investments, allowing multiple students to share a single device while maintaining individual learning profiles, app data, and files. Students sign in with school-issued Managed Apple IDs, access their personalized environment, complete assignments, and log out. Shared iPad integrates with Apple School Manager for automated roster syncing and supports Classroom app for teacher-led instruction across shared devices.

In Addigy

Addigy supports Shared iPad configuration through dedicated payloads that define user session settings, storage quotas, maximum users per device, and temporary session options. Admins configure Shared iPad during device enrollment through ADE, specifying whether to enable temporary sessions for guest users and how much on-device storage to allocate per user. Addigy’s interface displays which devices are configured as Shared iPads and provides reporting on user session activity and storage consumption.

Privacy-focused authentication service. Can be used with Managed Apple IDs to provide secure SSO for supported apps.

What to Know

Sign in with Apple provides a privacy-focused alternative to social login (Facebook, Google) by allowing users to authenticate with apps using their Apple ID without sharing personal information like email addresses or social profiles. For organizations using Managed Apple IDs, Sign in with Apple enables SSO for supported third-party apps while maintaining organizational control over identity and access. Apps that support Sign in with Apple can leverage federated authentication, allowing users to sign in with their corporate-managed Apple IDs rather than creating separate app-specific accounts.

Common Scenarios

Enterprise IT: Corporate IT encourages employees to use Sign in with Apple for work-related third-party apps when available, leveraging Managed Apple IDs for centralized identity management. This reduces password sprawl and ensures that app access is automatically revoked when employees leave and their Managed Apple IDs are disabled. IT should verify that apps support Managed Apple ID authentication, as some apps only support personal Apple IDs.

MSP: MSPs configure clients’ Managed Apple ID systems to support Sign in with Apple for approved business applications. This simplifies app access provisioning and integrates with the client’s existing identity infrastructure through federated authentication. MSPs should educate clients about the distinction between personal Apple ID and Managed Apple ID authentication, as user confusion is common.

Education: Schools deploy Sign in with Apple to simplify student access to educational apps, allowing students to sign in with school-issued Managed Apple IDs rather than creating individual app accounts. This reduces password management overhead, ensures student accounts remain under school control, and simplifies app access provisioning through Apple School Manager. Schools should verify that educational apps support Managed Apple ID authentication.

In Addigy

Addigy supports deploying Managed Apple ID configurations that enable Sign in with Apple across managed devices. When users encounter apps that support Sign in with Apple, they can authenticate using their Managed Apple ID credentials, which are managed through Addigy’s identity configuration payloads. Addigy does not directly control or restrict Sign in with Apple functionality—it’s managed through device-level Apple ID settings and app-level authentication choices.

A macOS troubleshooting mode that boots to a command-line interface with root access (Intel Macs only). Useful for advanced system repairs and diagnostics.

What to Know

Single User Mode provides direct command-line access to the macOS file system and system utilities when the graphical interface won’t load or more advanced troubleshooting is required than Recovery Mode provides. IT professionals use Single User Mode to manually repair file systems, reset passwords, modify system files, and diagnose boot failures at a deeper level than GUI tools allow. However, FileVault encryption prevents Single User Mode access unless disabled, and modern Macs with T2/Apple Silicon chips have largely replaced Single User Mode with Recovery Mode.

Common Scenarios

Enterprise IT: On older Intel Macs without T2 chips, IT uses Single User Mode to reset forgotten passwords, manually run file system checks, or modify system configurations preventing normal boot. However, modern security requirements typically prevent Single User Mode access via FileVault and Firmware Password.

MSP: MSPs historically used Single User Mode for advanced troubleshooting on client Macs, but modern security features and Apple Silicon architecture have made Recovery Mode the primary troubleshooting environment instead.

Education: School IT on older Mac fleets occasionally uses Single User Mode for deep troubleshooting and password resets on lab Macs, though modern deployments rely on FileVault and Firmware Password which prevent Single User Mode access.

In Addigy

Single User Mode operates completely outside of MDM, and modern Macs with FileVault and secure boot prevent its use. Addigy admins should instead guide users through Recovery Mode for troubleshooting, which provides similar repair capabilities with better security integration.

Apple’s intelligent voice assistant. In MDM, Siri can be restricted to prevent data access from the lock screen or disabled entirely for security.

What to Know

Siri restrictions are deployed to prevent unauthorized data access and enforce security policies on devices handling sensitive information. Siri on the lock screen can expose calendar appointments, contacts, messages, and email content without requiring device authentication, creating significant data leakage risks on lost or stolen devices. Organizations in regulated industries often disable Siri entirely to prevent voice-activated data access and eliminate risks of inadvertent data exposure through voice queries.

Siri also sends voice data to Apple’s servers for processing, raising privacy concerns for organizations with strict data handling requirements. While Apple anonymizes and encrypts Siri requests, some organizations prefer to disable Siri to maintain complete control over data transmission and eliminate any external processing of potentially sensitive voice queries.

Common Scenarios

Enterprise IT: Corporate IT typically restricts Siri on the lock screen while allowing it when the device is unlocked, balancing security with productivity. For devices handling highly sensitive data (executive devices, devices accessing patient records, financial systems), IT may disable Siri entirely. Some organizations allow Siri for general productivity (timers, reminders, unit conversions) while restricting access to corporate data through app-level permissions.

MSP: MSPs configure Siri restrictions based on client security requirements and industry regulations. Healthcare and financial services clients often disable Siri entirely to maintain compliance with HIPAA or PCI-DSS, while tech or creative clients may allow Siri for productivity. MSPs should establish Siri policies during client onboarding and apply restrictions consistently across the fleet.

Education: Schools restrict Siri on student devices to maintain classroom focus and prevent students from using voice commands to bypass restrictions or access content during tests. Some schools allow Siri for accessibility purposes while restricting its ability to read messages or emails. Teacher devices typically have Siri enabled for productivity and accessibility features.

In Addigy

Addigy’s Restrictions payload provides granular Siri controls including “Allow Siri” (completely disables Siri), “Allow Siri While Device is Locked” (prevents lock screen access), and “Allow Siri Suggestions” (controls Siri content recommendations). These restrictions apply on supervised devices and take effect immediately upon profile deployment. Admins can configure different Siri policies for different device groups based on security requirements.

A troubleshooting procedure for Intel-based Macs that resets the System Management Controller, which handles power management, thermal management, and hardware control.

What to Know

SMC Reset resolves hardware-related issues that don’t involve the operating system itself, including battery charging problems, fan behavior issues, display brightness control failures, and power management glitches. When Macs exhibit strange hardware behavior like fans running constantly, failure to wake from sleep, or incorrect battery status reporting, SMC reset often resolves these issues without requiring hardware replacement or OS reinstallation. It’s a low-risk troubleshooting step that addresses a specific category of hardware control issues.

Common Scenarios

Enterprise IT: Corporate IT guides users through SMC resets when company MacBooks won’t charge, display incorrect battery status, or have thermal management issues causing excessive fan noise. This resolves many hardware-related help desk calls without requiring device returns.

MSP: MSPs use SMC reset to troubleshoot client Mac hardware issues like charging failures, display problems, and power management glitches. This quick procedure often resolves issues remotely without requiring on-site hardware diagnosis.

Education: School IT performs SMC resets on lab MacBooks exhibiting charging issues, overheating problems, or display brightness control failures. This is especially common on heavily-used shared devices experiencing power-related glitches.

In Addigy

SMC reset requires local user action or physical device access, but Addigy can deploy documentation and self-service guides providing device-specific SMC reset instructions. After SMC reset, all MDM-managed settings continue to function normally as the reset only affects low-level hardware controllers.

SMTP is the internet standard communication protocol for electronic mail transmission. In MDM environments, MDM servers use SMTP to send email notifications for events like enrollment completion, policy violations, security alerts, and compliance reports.

What to Know

SMTP enables MDM platforms to deliver critical alerts and reports via email, providing notification channels that reach admins even when they’re not actively monitoring dashboards. Email notifications for compliance violations, failed check-ins, or security events enable timely response to issues requiring immediate attention. SMTP also enables automated reporting, with MDM systems generating scheduled compliance reports, device inventory summaries, or security audit logs delivered via email to stakeholders who may not have direct MDM access. Email remains a universal notification channel accessible across all devices and platforms.

However, SMTP configuration requires careful attention to security and deliverability. Modern email systems employ aggressive spam filtering, and MDM notification emails may be flagged as spam without proper SPF, DKIM, and DMARC configuration. SMTP credentials must be secured, as compromised SMTP accounts enable spam campaigns that damage organizational reputation. Many organizations use dedicated SMTP relay services (SendGrid, Mailgun) rather than direct SMTP to ensure deliverability and offload email infrastructure management.

Common Scenarios

Enterprise IT: Corporate MDM platforms integrate with internal Exchange servers or Office 365 SMTP relays to send alert notifications and scheduled reports. IT must configure SMTP authentication, ensure firewalls permit outbound SMTP traffic (typically port 587 for submission or 465 for SMTPS), and verify SPF records authorize the MDM server to send email on behalf of the corporate domain. Alert subscriptions should be carefully configured to avoid notification fatigue — excessive low-priority alerts train admins to ignore emails, missing critical security events.

MSP: MSPs configure SMTP for client MDM instances to deliver alerts to client IT contacts and MSP technicians. Multi-tenant configurations may use dedicated SMTP accounts per client or centralized relay services that track email delivery per client for billing purposes. MSPs should implement email deliverability monitoring to detect when client spam filters block MDM notifications, potentially causing missed alerts. Email templates should clearly identify the client, device, and issue severity to enable rapid triage.

Education: School districts configure SMTP to deliver daily or weekly device compliance reports to district technology coordinators, providing visibility into managed device fleet health without requiring daily dashboard monitoring. Notification emails for lost or stolen device reports enable rapid response to device security incidents. Education IT should configure appropriate recipient lists for different alert types, ensuring security incidents reach appropriate personnel without overwhelming general IT staff with routine operational notifications.

In Addigy

Addigy provides built-in email notification capabilities without requiring admins to configure SMTP servers, handling email delivery infrastructure automatically. Administrators configure email alert subscriptions and report schedules through the Addigy console, specifying which events trigger notifications and which recipients receive them. Addigy supports customizable alert thresholds and notification grouping to prevent alert fatigue while ensuring critical events reach appropriate personnel.

For organizations requiring integration with internal email systems or custom SMTP relays, Addigy can accommodate custom configurations. Addigy’s notification system includes options for immediate alerts, digest summaries, and scheduled reports, providing flexibility in how admins receive information about managed fleet status. Administrators can configure notification preferences per user, ensuring each team member receives relevant alerts without unnecessary noise.

SNMP is a protocol for collecting and organizing information about managed devices on IP networks. In MDM and enterprise Apple device management, SNMP is important for network infrastructure monitoring, such as monitoring switches, routers, and wireless access points that support the managed device infrastructure.

What to Know

While SNMP isn’t directly used for managing Apple devices, it’s critical for monitoring the network infrastructure that supports device management. Network monitoring via SNMP enables IT to detect issues affecting device connectivity before they cause widespread management failures — detecting switch port errors, wireless AP outages, or bandwidth saturation that could prevent devices from checking in with MDM. SNMP monitoring integrates with alerting systems to notify IT of infrastructure issues, enabling proactive resolution before users report problems.

SNMP data also supports capacity planning and troubleshooting. Monitoring switch port utilization helps IT identify network segments approaching capacity, while historical SNMP data reveals patterns that inform infrastructure upgrades. When troubleshooting MDM connectivity issues, SNMP can reveal network-level problems (interface errors, high latency, packet loss) causing device check-in failures. Most enterprise network monitoring platforms rely heavily on SNMP for collecting infrastructure health metrics.

Common Scenarios

Enterprise IT: Corporate network teams use SNMP to monitor switches, routers, and wireless controllers supporting managed devices. SNMP alerts notify IT when wireless APs go offline, potentially affecting hundreds of devices. Network monitoring dashboards aggregate SNMP data to provide visibility into infrastructure health across multiple sites. IT correlates MDM check-in failures with SNMP-detected network issues to distinguish device problems from infrastructure problems.

MSP: MSPs deploy network monitoring tools that use SNMP to monitor client network infrastructure, providing proactive alerts for issues affecting device management. Multi-client SNMP monitoring requires managing different SNMP community strings and access credentials across diverse client networks. MSPs use SNMP data to identify client network issues that may affect MDM operations before clients report device management problems.

Education: School network teams monitor campus network infrastructure via SNMP, tracking wireless AP status across multiple buildings to ensure student devices maintain connectivity. SNMP monitoring helps education IT detect and resolve network issues before they disrupt classroom instruction. Large school districts may have hundreds of network devices monitored via SNMP, requiring automated alerting to manage scale effectively.

In Addigy

Addigy itself doesn’t use SNMP directly for device management, as Apple’s MDM protocol provides device communication mechanisms. However, organizations using Addigy should implement SNMP-based network monitoring to ensure the network infrastructure supporting their managed fleet remains healthy. Network issues detected via SNMP monitoring may explain device check-in patterns or connectivity problems visible in Addigy dashboards.

When troubleshooting widespread device connectivity issues, Addigy support may recommend customers check their network monitoring systems (which typically use SNMP) to rule out infrastructure problems. Ensuring robust network infrastructure monitoring complements Addigy’s device management capabilities by providing visibility into the network layer that devices depend on for MDM communication.

Payload that manages operating system update behavior. Controls automatic checks, downloads, installation deferrals, and enforcement windows.

What to Know

Software updates contain critical security patches, bug fixes, and new features that protect devices from evolving threats and maintain compatibility with modern applications. The Software Update payload enables IT to balance security with stability by enforcing security updates quickly while deferring major OS releases for testing and validation. Without centralized update management, devices fall behind on patches, creating security vulnerabilities that attackers actively exploit.

Unmanaged updates create support challenges when users install major OS versions before enterprise applications are validated for compatibility. The Software Update payload provides control over update timing, user deferrals, and installation windows, ensuring updates occur during appropriate maintenance windows rather than disrupting business operations.

Common Scenarios

Enterprise IT: Enforcing security updates within 30 days while deferring major OS releases for 90 days to allow application testing. IT schedules forced update installations during off-hours and provides users with deferral options up to a deadline, after which updates install automatically.

MSP: Managing update policies across diverse client environments with varying risk tolerances and change management processes. MSPs create staged rollout plans where updates deploy first to pilot groups, then broader populations after validation, minimizing business disruption from compatibility issues.

Education: Deferring major updates during academic years to maintain stable classroom environments, then deploying updates during summer breaks when devices are not in active use. Schools balance security update urgency with instructional continuity and testing schedules.

In Addigy

Addigy’s Software Update payload configuration provides controls for automatic updates, deferral periods, installation deadlines, and user notification settings. Addigy allows separate policies for rapid security responses and major OS updates, enabling nuanced update management strategies. Addigy’s dashboard displays update compliance status and identifies devices running outdated OS versions requiring attention.

Addigy can enforce update installations through MDM commands and provides logging of update status, failures, and user deferrals. Addigy integrates with Addigy’s alerting system to notify admins when critical security updates are available or when devices exceed defined update deadlines.

SSH is a cryptographic network protocol for secure remote command-line access. In MDM and macOS management, SSH is used for remote administration of Macs, servers, and network infrastructure, enabling advanced troubleshooting and script execution.

What to Know

SSH enables secure command-line access to Macs for troubleshooting scenarios beyond MDM’s capabilities. While MDM excels at policy deployment and standard management tasks, complex troubleshooting often requires direct shell access to examine logs, test configurations, or execute commands interactively. SSH’s encrypted communication protects sensitive data and credentials during remote sessions, making it vastly superior to legacy protocols like Telnet. SSH key-based authentication eliminates password transmission, improving security and enabling automated remote management scripts.

SSH is essential for managing macOS servers, development workstations, and kiosk systems where direct console access isn’t practical. IT teams use SSH for tasks like reviewing system logs, restarting services, installing packages via command line, and executing diagnostic commands. However, SSH access requires careful security controls — unrestricted SSH access creates security risks, so organizations typically restrict SSH to specific administrator groups, require key-based authentication, and monitor SSH access logs for unusual activity.

Common Scenarios

Enterprise IT: Corporate IT enables SSH on macOS servers and critical workstations for remote administration, using SSH keys rather than passwords for authentication. SSH access policies restrict which networks can initiate SSH connections (internal networks only, or via VPN) and which user accounts have SSH access. IT uses SSH for emergency troubleshooting when devices experience issues preventing normal MDM communication. SSH bastions/jump hosts provide audited access paths for privileged SSH sessions to production systems.

MSP: MSPs use SSH for advanced troubleshooting on client Mac devices and servers, typically accessing devices through secure tunnels or VPN connections. MSPs should document which client devices have SSH enabled, maintain SSH key inventories, and implement SSH logging for compliance and audit purposes. Emergency access procedures may involve temporarily enabling SSH via MDM script when devices experience issues preventing remote screen sharing or other management tools from functioning.

Education: School IT departments typically disable SSH on student devices for security reasons, but enable SSH on teacher workstations and IT administrative Macs for support purposes. Computer labs and shared resources often have SSH enabled for remote management and classroom control. Education IT should implement SSH access controls that limit access to IT staff networks and use SSH key authentication rather than passwords to prevent unauthorized access attempts.

In Addigy

Addigy doesn’t rely on SSH for standard device management operations, using Apple’s MDM protocol instead. However, admins can enable SSH on managed devices through configuration profiles or scripts deployed via Addigy, then use SSH for advanced troubleshooting scenarios. Addigy’s remote terminal feature provides secure command-line access to managed Macs without requiring separate SSH configuration, offering similar capabilities with integrated authentication and session logging.

When SSH access is needed, admins can deploy profiles or scripts via Addigy to enable the SSH service, configure access controls, and deploy SSH authorized keys to managed devices. For security, SSH should only be enabled on devices requiring remote command-line access, with access restricted to specific administrator accounts. Addigy’s script execution capabilities often eliminate the need for SSH by allowing admins to run commands remotely through the MDM channel without maintaining persistent SSH access.

SSL/TLS are cryptographic protocols designed to provide secure communication over a computer network. In MDM environments, TLS is absolutely critical. All MDM server communications use HTTPS (HTTP over TLS). Device enrollment, command execution, and inventory reporting all depend on TLS.

What to Know

TLS (SSL’s successor) is the foundation of all secure internet communication, encrypting data in transit to prevent eavesdropping and tampering. For MDM, TLS protects sensitive device commands, user credentials, inventory data, and configuration profiles transmitted between devices and servers. TLS also provides server authentication through certificates, ensuring devices connect to legitimate MDM servers rather than impersonators. Modern TLS versions (1.2 and 1.3) provide strong encryption that resists known attacks, while older versions (SSL 3.0, TLS 1.0) are deprecated due to security vulnerabilities.

TLS configuration directly impacts both security and compatibility. Weak cipher suites enable attacks, while overly restrictive configurations prevent older devices from connecting. Certificate validation failures (expired certificates, hostname mismatches, untrusted CAs) break MDM enrollment and check-ins entirely. Organizations must balance security (strong ciphers, current TLS versions) with compatibility (supporting devices that may lag behind current standards). TLS inspection by enterprise security tools can inadvertently break certificate validation by presenting substitute certificates devices don’t trust.

Common Scenarios

Enterprise IT: Corporate MDM servers require valid TLS certificates from trusted CAs, with IT monitoring expiration dates and renewing certificates before they expire. Load balancers and reverse proxies terminating TLS connections must be configured with appropriate cipher suites and TLS versions that balance security with device compatibility. SSL/TLS inspection proxies deployed for security monitoring must be carefully configured to avoid breaking MDM traffic, often requiring MDM traffic bypass rules. Certificate validation failures are among the most common causes of enrollment and check-in issues.

MSP: MSPs managing hosted MDM infrastructure must maintain current TLS certificates across all client instances and configure TLS settings that support the oldest devices clients need to manage while maintaining reasonable security posture. Automated certificate renewal through services like Let’s Encrypt simplifies certificate lifecycle management. MSPs should monitor TLS handshake failures in MDM logs to detect devices with outdated TLS implementations that may require special handling or upgrade recommendations.

Education: Educational institutions must ensure MDM server TLS certificates are valid and trusted by all managed devices, including student BYOD devices that may not trust internal CAs. Public CA certificates simplify deployment but require tracking renewal schedules and coordinating certificate updates across potentially complex infrastructure (load balancers, proxies, firewalls). School network security tools performing TLS inspection must exclude MDM traffic to prevent certificate validation failures that break device management.

In Addigy

Addigy’s cloud-hosted infrastructure handles all TLS certificate management automatically, using industry-standard certificates trusted by all Apple devices. Addigy implements current TLS best practices, supporting TLS 1.2 and 1.3 with strong cipher suites while maintaining compatibility with Apple’s supported device range. Administrators don’t need to manage certificates, configure TLS settings, or monitor for certificate expiration — Addigy’s infrastructure team handles these operations transparently.

For organizations with TLS inspection proxies or other security infrastructure that may interact with MDM traffic, Addigy support can provide guidance on configuring bypass rules to prevent TLS inspection from breaking device-to-Addigy communication. Addigy’s HTTPS endpoints follow Apple’s security recommendations, ensuring encrypted communication for all device management operations. When troubleshooting enrollment or connectivity issues, Addigy support can analyze TLS handshake logs to identify certificate validation problems or TLS configuration issues in customer network environments.

A macOS Recovery tool that configures security settings for the startup disk, including Secure Boot, external boot permissions, and firmware password on Apple Silicon Macs.

What to Know

Startup Security Utility controls fundamental security policies that govern how Macs boot and what software they trust during startup. Configuring these settings is essential for balancing security requirements with operational needs, such as allowing external boot for troubleshooting while maintaining Secure Boot for production use. For organizations with compliance requirements, Startup Security Utility settings determine whether Macs meet security baselines for protecting against bootkits and unauthorized OS modifications.

Common Scenarios

Enterprise IT: Corporate IT configures Startup Security Utility settings via MDM or manually to enforce Full Security mode with Secure Boot, preventing unauthorized OS modifications while still permitting necessary functionality like external boot for IT support purposes.

MSP: MSPs configure Startup Security settings on client Macs based on security requirements and operational needs, balancing protection against boot-level threats with the ability to perform external boot diagnostics when needed.

Education: School IT typically configures Startup Security to Full Security mode on faculty Macs handling student data, while potentially relaxing settings on lab Macs to permit external boot for rapid troubleshooting and reimaging.

In Addigy

Addigy can deploy Startup Security Utility settings via MDM on supported Macs, allowing centralized enforcement of Secure Boot policies, external boot permissions, and password requirements without requiring manual configuration on each device.

Payload that manages allowed system extensions on macOS (the modern replacement for kernel extensions). Allows extensions by team or bundle ID to bypass user prompts.

What to Know

System extensions provide a modern, more secure alternative to kernel extensions by running in user space rather than kernel space, reducing the risk of system instability and security vulnerabilities. macOS requires user approval for system extensions to prevent malicious software from gaining elevated privileges. The System Extension payload allows IT to pre-approve trusted extensions for enterprise software, ensuring seamless deployment of security tools, network filters, and endpoint protection without user prompts.

As Apple phases out kernel extension support, system extensions become essential for modern enterprise software. Organizations must transition from KEXT-based tools to system extension equivalents to maintain compatibility with current and future macOS versions.

Common Scenarios

Enterprise IT: Pre-approving system extensions for next-generation endpoint security platforms, DNS filtering tools, and corporate VPN clients. IT maintains approved extension lists and updates policies as vendors migrate from KEXTs to system extensions, ensuring continuous functionality during macOS upgrades.

MSP: Managing system extension approvals across client environments with varied security tool portfolios. MSPs track vendor migration timelines from KEXTs to system extensions and proactively update client policies to prevent compatibility issues during macOS update cycles.

Education: Approving system extensions for content filtering software, classroom management tools, and student safety applications. Schools ensure approved extensions maintain functionality as educational software vendors modernize their platforms for current macOS security architectures.

In Addigy

Addigy’s System Extension payload configuration allows admins to approve extensions by Team ID or bundle identifier, with separate controls for different extension types including network extensions, endpoint security, and driver extensions. Addigy provides templates for commonly deployed enterprise applications and validates extension identifiers before deployment.

Addigy’s catalog indicates which applications require system extensions versus deprecated KEXTs, helping admins plan compatibility strategies for fleet-wide macOS upgrades. Addigy logs extension approval status and provides troubleshooting guidance when applications fail to load due to missing approvals.

Protects critical macOS system files from modification, even by root users. Can only be disabled from Recovery Mode.

What to Know

System Integrity Protection prevents even privileged users and processes from modifying protected system files, directories, and processes. This drastically reduces the attack surface for rootkits and malware that attempt to compromise core system components. By restricting modifications to critical system areas (/System/, /usr/, pre-installed applications), SIP ensures that macOS maintains a known-good state and that malicious software cannot hide within system directories or replace system binaries.

For enterprise IT, SIP affects software that attempts to modify system components or inject code into system processes. While this strengthens security, it can break legacy management tools, endpoint protection solutions, or utilities that rely on kernel extensions or system modification. Understanding SIP limitations helps IT plan deployments and identify when tools need updating to work within SIP constraints.

Common Scenarios

Enterprise IT: Security and compliance teams enforce SIP to maintain system integrity and prevent unauthorized system modifications. When deploying endpoint security tools or monitoring software, IT must verify that solutions are SIP-compatible and use approved extension mechanisms (System Extensions, Endpoint Security Framework) rather than deprecated kernel extensions.

MSP: MSPs audit SIP status across client fleets to ensure devices maintain protection. If clients request SIP be disabled for specific software, MSPs document the business justification, assess security risks, and recommend alternative solutions that work within SIP constraints whenever possible.

Education: Schools maintain SIP enabled on all devices to prevent students or unauthorized users from tampering with system files. This is particularly important for shared lab computers and student devices where multiple users may have administrative access for legitimate educational purposes.

In Addigy

Addigy can report on SIP status for managed Macs through device inventory, showing whether SIP is enabled, disabled, or partially disabled. While Addigy cannot remotely disable SIP (Apple requires local access via Recovery Mode for security reasons), admins can use Addigy to identify devices with unexpected SIP states and investigate potential security policy violations or unauthorized modifications.

Text files and databases that record system events, errors, and diagnostic information. Crucial for diagnosing MDM issues via mdmclient logs.

What to Know

System Logs provide detailed evidence of what the operating system and applications are doing behind the scenes, including error messages, security events, authentication attempts, and system state changes. When troubleshooting mysterious device issues, crashes, or security incidents, system logs contain the technical details necessary to identify root causes. Without log analysis, troubleshooting becomes guesswork rather than evidence-based diagnosis.

Common Scenarios

Enterprise IT: Corporate IT reviews system logs to diagnose MDM enrollment failures, authentication issues with enterprise services, kernel panics, and application crashes. Logs provide concrete evidence of what failed and when, enabling targeted fixes rather than trial-and-error troubleshooting.

MSP: MSPs analyze client device system logs when troubleshooting persistent issues that don’t produce obvious error messages. Log analysis helps identify failing services, software conflicts, and hardware issues that would otherwise require extensive on-site diagnosis.

Education: School IT examines system logs to diagnose classroom management software failures, student authentication issues, and shared device sync problems. Log data reveals the specific errors causing problems across large deployments of student devices.

In Addigy

Addigy enables remote log collection via custom scripts that gather relevant log files and upload them for offline analysis. Administrators can also use Addigy’s Remote Desktop feature to access Console and view real-time logs during troubleshooting sessions without requiring physical device access.

A Mac startup mode that makes the Mac’s internal drive appear as an external disk when connected to another computer. Useful for data recovery.

What to Know

Target Disk Mode enables direct file-level access to a Mac’s internal storage from another Mac, bypassing the need for the target Mac to boot into macOS. This is essential for data recovery when a Mac won’t boot but the drive is still accessible, for rapid large-file transfers between Macs, and for performing disk repairs or diagnostics from a known-good system. IT teams use Target Disk Mode to quickly extract user data from failing Macs before reimaging or to migrate data between devices faster than network transfers allow.

Common Scenarios

Enterprise IT: Corporate IT uses Target Disk Mode to recover user data from Macs with corrupted operating systems before performing warranty replacements or reimaging. This ensures employee files are preserved even when the Mac won’t boot normally.

MSP: MSPs use Target Disk Mode to quickly transfer client data between old and new Macs during device refreshes, or to extract data from Macs with boot failures before attempting repairs. This is faster than network migration and works even when macOS won’t start.

Education: School IT uses Target Disk Mode to rapidly transfer data from failing lab Macs to replacement systems, or to extract student project files from Macs requiring reimaging. This minimizes data loss and speeds up device recovery processes.

In Addigy

Target Disk Mode operates below the OS level and requires physical device connectivity, so it functions outside of MDM. However, Addigy can deploy documentation instructing IT staff on using Target Disk Mode for data recovery. Once the Mac boots normally again, Addigy management resumes automatically.

TCP/IP is the foundational suite of communication protocols used to interconnect network devices. In MDM environments, TCP/IP is the foundation of all network communication. Devices use TCP/IP to communicate with MDM servers (HTTPS over TCP) and receive push notifications (APNs over TCP).

What to Know

TCP/IP is the universal language of internet communication, enabling devices to send and receive data across networks of any size or complexity. Every MDM operation — enrollment, check-ins, app downloads, profile installations — relies on TCP/IP connectivity. TCP provides reliable, ordered delivery of data packets, ensuring MDM commands arrive intact and in sequence. IP addressing and routing enable devices to locate and reach MDM servers across complex enterprise networks or the public internet. Without functioning TCP/IP connectivity, devices are isolated and cannot be managed remotely.

Network troubleshooting for MDM issues frequently involves diagnosing TCP/IP problems: incorrect IP addressing (DHCP failures), routing issues (devices on wrong VLANs or subnets), firewall rules blocking required ports, or DNS failures preventing hostname resolution. Understanding TCP/IP fundamentals helps IT diagnose whether enrollment failures stem from device issues, network infrastructure problems, or MDM server configuration errors. TCP/IP monitoring and diagnostics (ping, traceroute, packet capture) are essential tools for troubleshooting device connectivity issues.

Common Scenarios

Enterprise IT: Corporate networks use DHCP to assign IP addresses automatically, but misconfigurations can prevent devices from obtaining addresses or reaching critical services. Firewall rules must permit TCP traffic on specific ports (443 for HTTPS MDM communication, 2195/2196/5223 for APNs). Network segmentation via VLANs requires proper routing configuration to allow managed devices to reach MDM servers and external Apple services. IT troubleshooting device check-in failures should verify basic TCP/IP connectivity (can device ping gateway, reach DNS, access internet) before investigating MDM-specific issues.

MSP: MSPs troubleshooting client device issues must understand client network topology, IP addressing schemes, and firewall configurations that affect TCP/IP connectivity. Client network changes (new firewalls, VLAN reconfigurations, ISP changes) can break previously-functioning MDM operations by blocking required TCP ports or preventing routing to MDM servers. MSPs should document client network requirements for MDM traffic and verify TCP/IP connectivity during initial deployment and after any network infrastructure changes.

Education: School networks with aggressive security policies may inadvertently block TCP ports required for MDM communication. Student devices roaming between buildings or using guest Wi-Fi may experience IP addressing issues if DHCP scopes are exhausted or misconfigured. Education IT should ensure TCP/IP connectivity for managed devices across all campus network segments, including wireless networks, wired classrooms, and administrative areas. Port restrictions on student VLANs must permit MDM traffic even while blocking other services for security reasons.

In Addigy

Addigy’s MDM communication relies on standard TCP/IP protocols, with devices connecting to Addigy servers via HTTPS (TCP port 443) and receiving push notifications via APNs (TCP ports 2195, 2196, 5223). Addigy’s network requirements documentation specifies which hosts and ports must be accessible for full functionality. When troubleshooting device connectivity issues, Addigy support helps admins verify TCP/IP connectivity from device networks to Addigy and Apple services.

Organizations should ensure network infrastructure permits TCP/IP traffic to Addigy endpoints and Apple services, with firewall rules allowing outbound connections on required ports. Addigy’s cloud architecture eliminates the need for organizations to configure inbound firewall rules or complex routing — devices initiate outbound TCP connections to Addigy, simplifying network configuration. Addigy’s diagnostics can help identify TCP/IP connectivity issues by testing reachability of required endpoints from problem devices.

The collection of utilities used to diagnose and resolve device issues, including Apple Diagnostics, Disk Utility, Console, and terminal commands.

What to Know

Troubleshooting Tools provide structured approaches to diagnosing and resolving device issues rather than relying on trial-and-error or guesswork. Tools like Console, Activity Monitor, Network Utility, and Disk Utility expose system state, resource usage, network conditions, and storage health that aren’t visible in normal user interfaces. For IT professionals managing device fleets, familiarity with these tools is essential for rapid problem resolution and avoiding unnecessary hardware replacements or OS reinstalls.

Common Scenarios

Enterprise IT: Corporate IT trains support staff on troubleshooting tools to diagnose user-reported issues efficiently, determining root causes and appropriate solutions without defaulting to full device wipes or costly replacements.

MSP: MSPs use troubleshooting tools to remotely diagnose client device issues and provide concrete evidence supporting recommendations for software fixes versus hardware replacement. This ensures billable hours are spent productively and clients receive accurate service.

Education: School IT trains student technicians and help desk staff on basic troubleshooting tools like Activity Monitor and Console to handle first-tier support, reducing escalations to central IT and improving support response times.

In Addigy

Addigy’s Remote Desktop feature allows admins to access all built-in troubleshooting tools remotely, enabling real-time diagnosis without physical device access. Addigy can also deploy custom diagnostic scripts that leverage troubleshooting utilities and upload results for centralized analysis.

A device state indicating the device has no active MDM enrollment and is not under management control.

What to Know

Unenrolled devices lose all MDM-applied configurations, profiles, and managed apps. Depending on profile settings, managed data may be removed during unenrollment. For corporate-owned devices, unenrollment represents a security and compliance risk since IT can no longer enforce policies, deploy updates, or remotely wipe the device. Unenrollment can be intentional (IT removes a device, user leaves the organization) or unintentional (user removes profile, certificate expires).

Common Scenarios

Enterprise IT: Devices are intentionally unenrolled when employees leave, hardware is retired, or devices are reassigned. Unintentional unenrollment occurs when users remove profiles from unsupervised devices or when MDM certificates expire. IT should audit for unexpected unenrollments and enforce policies that prevent profile removal on corporate-owned devices.

MSP: Client offboarding workflows should include formal unenrollment steps to remove devices from billing and management. MSPs should alert clients when devices unenroll unexpectedly, as this can indicate user tampering, device theft, or technical issues requiring attention.

Education: Student devices should remain enrolled for the duration of the academic year or ownership period. Unenrollment during the school year typically indicates device loss, damage, or student attempts to bypass restrictions. Schools should monitor unenrollment events and investigate anomalies.

In Addigy

When a device unenrolls, Addigy marks it as inactive and stops sending commands or profiles. Admins can view unenrollment history and re-enroll devices by sending a new enrollment profile. Addigy retains device records after unenrollment for historical reporting and can alert admins when devices unexpectedly drop out of management.

Allows copying content on one device and pasting on another. Can be managed via MDM to prevent data transfer between personal and corporate devices.

What to Know

Universal Clipboard creates significant data leakage risks when users mix personal and corporate devices, as it enables seamless copy-paste operations across devices signed in to the same Apple ID. An employee could copy sensitive corporate data on a managed Mac and paste it into a personal iPhone Notes app, email, or messaging service—bypassing DLP controls, audit trails, and corporate data boundaries. For organizations with strict data governance requirements, Universal Clipboard is one of the highest-priority Continuity features to restrict.

Common Scenarios

Enterprise IT: Corporate IT restricts Universal Clipboard on devices handling sensitive data to prevent inadvertent data transfer to personal devices. Organizations with BYOD programs universally disable Universal Clipboard on corporate devices to prevent work content from being pasted into personal apps. Some organizations allow Universal Clipboard only between corporate-managed devices (both Mac and iPhone managed by MDM) while blocking it when personal devices are present.

MSP: MSPs disable Universal Clipboard by default on all client devices as a baseline data security measure, particularly for clients in regulated industries. Clients concerned about productivity impacts may request exceptions, but most accept the restriction once they understand the data leakage risks. MSPs should explain Universal Clipboard restrictions during onboarding to prevent user confusion when clipboard syncing stops working after MDM enrollment.

Education: Schools restrict Universal Clipboard on student devices to prevent students from copying answers between devices during tests or transferring school-owned content to personal devices. Shared student devices typically have Universal Clipboard disabled to prevent cross-contamination of clipboard data between students. Teacher devices may allow Universal Clipboard if the school permits teachers to use both personal and school-issued devices.

In Addigy

Addigy’s Restrictions payload includes an “Allow Universal Clipboard” toggle that prevents clipboard syncing across devices when disabled. This restriction requires a supervised device and applies immediately upon profile deployment. Disabling Universal Clipboard does not affect local clipboard functionality—users can still copy and paste within the same device normally. Addigy does not currently offer granular control to allow Universal Clipboard only between managed devices.

A device state where the device has no MDM enrollment and operates as a consumer device without organizational oversight or policies.

What to Know

Unmanaged devices accessing corporate resources create security blind spots. IT cannot enforce encryption, passcode requirements, or app restrictions, and has no ability to remotely wipe data if the device is lost. Unmanaged devices also lack automated patching, increasing exposure to vulnerabilities. Organizations that permit unmanaged device access often implement conditional access policies that limit what resources unmanaged devices can reach.

Common Scenarios

Enterprise IT: Unmanaged devices include personal devices that access corporate email or cloud services without enrolling in MDM, contractor devices, or older hardware that predates the MDM program. IT should enforce conditional access to ensure unmanaged devices cannot access high-sensitivity resources like file servers, internal databases, or source code repositories.

MSP: Clients often have mixed fleets with legacy unmanaged devices alongside newly managed hardware. MSPs should identify unmanaged devices, assess risk, and propose enrollment or replacement strategies. Some clients accept limited unmanaged access for low-risk users or contractors to avoid the cost of full device management.

Education: Unmanaged devices in education settings typically include parent-owned BYOD devices or guest devices used by visitors. Schools should segment network access so unmanaged devices connect to isolated guest Wi-Fi without access to student data, administrative systems, or internal resources.

In Addigy

Addigy does not track unmanaged devices unless they attempt to enroll or are manually added as placeholders. To identify unmanaged devices on the network, admins should integrate network access control (NAC) tools or conditional access policies that report device enrollment status before granting resource access.

A device state where the device can be managed through MDM but does not have supervision enabled, limiting available management capabilities.

What to Know

Unsupervised devices can only receive a limited subset of MDM restrictions and commands. Users retain the ability to remove the MDM profile in Settings, and many high-security controls (like preventing app deletion, restricting AirDrop, or enabling Managed Lost Mode) are unavailable. For corporate-owned devices or environments with strict security requirements, unsupervised management creates compliance gaps and increases the risk of users bypassing organizational policies.

Common Scenarios

Enterprise IT: Unsupervised devices typically occur when manually enrolling legacy devices or when users bring their own devices. BYOD programs often accept unsupervised status since supervision requires factory reset and organizational ownership. For corporate-owned devices, IT should avoid unsupervised status whenever possible.

MSP: Legacy client devices that were manually enrolled before ADE adoption remain unsupervised unless re-enrolled. MSPs should communicate the limitations to clients and recommend ADE migration during hardware refresh cycles or when policies require enhanced control.

Education: Unsupervised student devices severely limit classroom management capabilities, making it difficult to enforce app restrictions, content filtering, or prevent profile removal. Schools should prioritize supervised enrollment through ASM for all student-facing devices.

In Addigy

Addigy displays the supervision status for each device in the device details page. Policies and restrictions that require supervision are clearly labeled in the Catalog, preventing admins from deploying unsupported configurations. When viewing a device’s profile list, Addigy indicates which profiles are applied and which are blocked due to unsupervised status.

An enrollment method designed for personally-owned devices that separates work and personal data (via separate APFS volume) while limiting MDM management capabilities to protect user privacy.

What to Know

User Enrollment is Apple’s purpose-built solution for BYOD scenarios, providing a privacy-focused middle ground between full device management and no management at all. Introduced in iOS 13 and macOS 10.15, User Enrollment creates a separate APFS volume for managed data, ensuring complete separation between personal and work content. MDM can only see and manage work-related apps, accounts, and data, while personal information remains completely private and inaccessible to IT. This technical separation addresses employee privacy concerns while giving organizations necessary control over corporate data.

User Enrollment requires a Managed Apple ID and authentication through the organization’s identity provider, tying enrollment to the user’s work identity rather than the device itself. When a user leaves the organization, removing the Managed Apple ID cleanly removes all work data and management without affecting personal content. This makes User Enrollment ideal for organizations with strict privacy requirements, unionized workforces, or regulations prohibiting invasive device monitoring.

Common Scenarios

Enterprise IT: Employees with personal iPhones enroll via User Enrollment to access corporate email and Slack while keeping personal photos, messages, and apps completely private. IT can enforce policies on managed apps—requiring passcodes, preventing screenshots in work apps, enabling remote wipe of work data—without seeing or controlling anything personal. When employees leave, IT removes the Managed Apple ID, instantly deleting all corporate data while preserving personal content.

MSP: MSPs recommend User Enrollment for clients with BYOD policies or privacy concerns. The MSP configures User Enrollment in Apple Business Manager, sets up identity provider integration, and creates policies that apply only to managed apps. This provides clients with necessary corporate data protection while respecting employee privacy, reducing friction in BYOD policy adoption and maintaining clear legal boundaries around device management.

Education: Universities deploy User Enrollment for student-owned devices accessing institutional resources. Students enroll their personal iPads to receive campus apps, email, and Wi-Fi certificates, but the university cannot see personal apps, location, or browsing history. The clear privacy separation increases student willingness to enroll while giving the university necessary control over institutional data and app distribution.

In Addigy

Addigy supports User Enrollment through Apple Business Manager integration with Managed Apple IDs. You configure User Enrollment policies that define which apps and settings apply to the managed volume, while Addigy automatically respects the privacy boundaries of User Enrollment. Devices enrolled via User Enrollment are clearly designated in Addigy’s inventory, and Addigy prevents deployment of policies or commands that would violate User Enrollment privacy restrictions.

Addigy’s User Enrollment workflow includes Managed Apple ID authentication, automatic creation of the separate managed volume, and deployment of work apps to the managed partition only. You can manage VPP app licenses, enforce managed app restrictions, and remotely remove the managed volume without affecting personal data. Addigy’s reporting shows only managed content, maintaining privacy compliance throughout the device lifecycle.

A requirement introduced in macOS High Sierra 10.13.2 where users must manually approve MDM enrollment to grant certain management capabilities.

What to Know

User-Approved MDM (UAMDM) is required on macOS for kernel extensions, system extensions, FileVault escrow, software updates, and other privileged operations. Without user approval, MDM enrollment is limited to basic profile installation and cannot enforce critical security controls. ADE-enrolled devices bypass the user approval requirement, making ADE essential for zero-touch deployment and full management of corporate-owned Macs.

Common Scenarios

Enterprise IT: Manual enrollment of Macs requires users to approve enrollment in System Preferences/Settings, which can be a friction point during onboarding. IT should prioritize ADE enrollment for corporate-owned Macs to eliminate the user approval step. For existing manually-enrolled devices, IT may need to prompt users to approve the enrollment if privileged management features suddenly stop working after a macOS update.

MSP: Clients with legacy Macs that were manually enrolled before ADE adoption may lack user-approved status, causing silent failures when deploying kernel extensions or software updates. MSPs should audit enrollment status and guide clients through the approval process or recommend ADE migration during the next hardware refresh cycle.

Education: School-managed Macs should be ADE-enrolled to avoid requiring students or teachers to manually approve enrollment. In BYOD scenarios where personal Macs connect to school resources, User-Approved MDM provides a balance between institutional control and user consent, though schools should clearly communicate what approval grants access to.

In Addigy

Addigy displays whether a macOS device has user-approved enrollment status in the device details page. For manually-enrolled devices without approval, Addigy provides instructions for users to approve enrollment via System Preferences > Profiles. ADE-enrolled devices automatically have approved status, so admins do not need to track or remediate approval for those devices.

A device enrollment method where the user manually installs an MDM enrollment profile, typically resulting in unsupervised status.

What to Know

User enrollment represents a voluntary MDM relationship where users manually install enrollment profiles, typically for BYOD programs or legacy devices that predate ADE. Because enrollment is user-initiated, devices remain unsupervised and users retain the ability to remove MDM profiles at will. This creates a less secure management posture compared to ADE enrollment, with fewer available restrictions and no guarantee of continuous management. Organizations must understand these limitations when developing enrollment strategies and BYOD policies.

User-enrolled devices are appropriate for scenarios where organizations need basic management and configuration capabilities without full device control. However, for corporate-owned devices or environments requiring strict security enforcement, user enrollment is insufficient. The voluntary nature of user enrollment means IT cannot rely on it for devices that must remain under continuous management or enforce mandatory security controls.

Common Scenarios

Enterprise IT: BYOD programs allow employees to user-enroll personal devices to access corporate email and intranet resources. Users install an enrollment profile to configure Exchange and VPN settings, but retain the ability to remove management if they leave the company or no longer wish to participate in the program. This respects user device ownership while providing IT with basic configuration capabilities.

MSP: Legacy client devices purchased before the MSP relationship began cannot be enrolled through ADE without factory reset. MSPs user-enroll these devices to gain basic management until the next hardware refresh cycle, when devices can be properly ADE-enrolled. MSPs document these exceptions and prioritize migration to supervised enrollment during client reviews.

Education: Faculty who bring personal iPads for classroom use can user-enroll to access school Google Workspace or learning management systems. The school gains ability to deploy necessary apps and configurations without requiring full supervision of personal devices. Teachers can unenroll at any time, making this appropriate for personal device management.

In Addigy

Addigy generates enrollment invitations that users can install via email, SMS, or self-service portals for user-enrolled devices. These profiles install with unsupervised status, and Addigy clearly indicates supervision state in device inventory. Admins can deploy policies and restrictions that work on unsupervised devices, though Addigy’s interface indicates which management capabilities require supervision and won’t apply to user-enrolled devices.

A macOS startup mode that displays detailed system messages during boot instead of the Apple logo, useful for diagnosing startup hangs.

What to Know

Verbose Mode exposes the detailed startup process normally hidden behind the Apple logo, showing exactly which system components are loading, which drivers are initializing, and where boot failures occur. When Macs fail to boot or hang during startup, Verbose Mode provides essential diagnostic information that reveals the specific component or process causing the failure. This transforms vague “won’t start” issues into actionable diagnostic data showing precisely where the boot process fails.

Common Scenarios

Enterprise IT: Corporate IT instructs users to boot into Verbose Mode when Macs hang during startup, capturing photos or videos of the verbose output that shows exactly which process is failing. This enables targeted troubleshooting rather than generic “boot issues” help desk tickets.

MSP: MSPs guide clients through Verbose Mode boots during remote troubleshooting calls, using the verbose output to diagnose startup failures and determine if the issue is driver-related, filesystem corruption, or hardware failure.

Education: School IT uses Verbose Mode to diagnose lab Macs that hang during startup, identifying problematic LaunchDaemons, kernel extensions, or filesystem issues that standard boot modes don’t reveal.

In Addigy

Verbose Mode must be activated locally during boot, but Addigy can deploy user-facing guides and documentation explaining how to enable it for troubleshooting. After diagnosing boot issues via Verbose Mode and resolving them, Addigy management resumes normally once macOS starts successfully.

Payload that configures VPN connections (IKEv2, IPsec, L2TP, Custom SSL). Supports Per-App VPN and On-Demand rules for automatic connection.

What to Know

VPN payloads enable secure remote access to corporate resources by encrypting network traffic and routing it through organizational infrastructure. Deploying VPN configurations via MDM eliminates manual setup, reduces configuration errors, and ensures consistent security policies across remote workers. Always-on VPN and per-app VPN capabilities provide granular control over which traffic flows through corporate networks versus public internet, balancing security with performance.

VPN configurations contain sensitive authentication credentials and server details that should never be manually shared with users. MDM-delivered VPN payloads protect these credentials, enable centralized configuration updates, and allow IT to remotely disable VPN access when devices are offboarded or compromised.

Common Scenarios

Enterprise IT: Deploying always-on VPN for remote workers accessing internal applications, file shares, and cloud resources. IT configures on-demand VPN rules that automatically connect when accessing corporate domains while allowing direct internet access for general browsing, optimizing both security and performance.

MSP: Managing VPN configurations for multiple client environments with different network architectures and security requirements. MSPs deploy per-app VPN for specific business applications while maintaining separate VPN profiles for different client sites or security zones.

Education: Providing secure remote access for faculty and admins accessing student information systems and administrative applications from home. Schools implement split-tunnel VPN configurations that protect sensitive traffic while allowing direct internet access for video streaming and general web usage.

In Addigy

Addigy’s VPN payload configuration supports all major VPN protocols and provides options for always-on connections, on-demand rules, and per-app VPN assignments. Addigy can bundle VPN configurations with SCEP payloads for certificate-based authentication and with DNS settings for split-tunnel configurations. Addigy validates VPN payload syntax before deployment and provides troubleshooting logs when connections fail.

When VPN credentials change or servers are migrated, Addigy enables centralized profile updates that automatically reconfigure all affected devices. Addigy displays VPN connection status in device inventory and can alert admins to devices experiencing persistent VPN connection failures.

VPN protocols establish secure, encrypted connections over public networks. IKEv2/IPsec is Apple’s recommended VPN protocol for iOS and macOS due to its security and mobility support. MDM admins can deploy VPN profiles to configure these connections automatically.

What to Know

VPNs enable secure remote access to corporate networks, encrypting traffic to protect data when devices connect from untrusted networks (home internet, coffee shop Wi-Fi, cellular). For organizations with on-premises resources (file servers, internal applications, databases), VPNs provide the secure connectivity layer enabling remote work. IKEv2 specifically handles network transitions gracefully — when devices switch between Wi-Fi and cellular, IKEv2 automatically re-establishes the VPN connection without user intervention, maintaining seamless access to corporate resources. Modern Always-On VPN configurations ensure devices maintain VPN connectivity whenever outside trusted networks, enforcing security policies before allowing network access.

MDM deployment of VPN profiles eliminates manual configuration, reduces support burden, and enables centralized VPN policy management. IT can configure split-tunnel routing (only corporate traffic through VPN) or full-tunnel (all traffic through VPN), certificate-based authentication (eliminating passwords), and per-app VPN rules (only specific apps use VPN). VPN authentication can integrate with corporate identity systems (Active Directory, Azure AD) for centralized credential management and access control.

Common Scenarios

Enterprise IT: Corporate remote access policies typically require VPN for accessing internal resources from external networks. IT deploys VPN profiles via MDM that configure IKEv2 connections with certificate-based authentication, eliminating password management. Always-On VPN configurations force devices to connect to VPN before allowing network access, ensuring security policies apply before users access any resources. Split-tunnel configurations route only corporate traffic through VPN, improving performance for internet-bound traffic while protecting corporate data. Per-app VPN rules enable specific applications (internal web apps, file sharing) to automatically trigger VPN connections.

MSP: MSPs configure client-specific VPN profiles for remote access to client networks, often using certificate-based authentication for improved security and reduced password management overhead. Multi-client MSP deployments require managing different VPN endpoints, authentication credentials, and routing configurations per client. MSPs should implement VPN connection monitoring to detect authentication failures, certificate expiration, or connectivity issues affecting remote workers. VPN troubleshooting often involves verifying firewall rules, certificate validity, and authentication server accessibility.

Education: School districts deploy VPN profiles to teacher and IT staff devices for secure remote access to student information systems, file servers, and administrative applications. Student devices typically don’t require VPN access, though distance learning scenarios may require VPN for accessing on-premises learning management systems. Education VPN deployments must balance security (protecting student data) with usability (minimizing complexity for teachers). Certificate-based authentication simplifies VPN access while maintaining security, avoiding password-related support calls.

In Addigy

Addigy enables admins to deploy VPN configuration profiles that configure IKEv2, IPsec, L2TP, and SSL VPN connections on managed devices. Administrators configure VPN settings including server addresses, authentication methods, and routing rules through the Addigy console, then deploy profiles to devices or device groups. Addigy supports certificate-based VPN authentication by deploying identity certificates alongside VPN profiles, enabling password-less VPN access.

Addigy’s VPN profile configuration includes options for Always-On VPN, per-app VPN rules, split-tunnel vs. full-tunnel routing, and on-demand connection rules that automatically establish VPN when accessing specific domains or networks. Administrators can deploy multiple VPN profiles to support different use cases (corporate network access, remote desktop, specific application access). Addigy’s deployment controls enable staged rollouts and easy profile updates when VPN infrastructure changes require configuration adjustments.

Apple’s program (now in ABM/ASM) for purchasing app licenses in bulk. Enables silent installation (Managed Distribution) without user Apple IDs.

What to Know

VPP fundamentally changes how organizations deploy App Store apps by eliminating the requirement for users to have personal Apple IDs to install managed apps. Before VPP, IT departments had to either share a single Apple ID across devices (violating Apple’s Terms of Service), require users to purchase apps with personal accounts (creating ownership confusion), or skip App Store apps entirely. VPP licenses are organization-owned and can be silently installed, revoked, and reassigned as needed.

For organizations managing large fleets, VPP also provides critical cost control and license management capabilities. Licenses can be purchased in bulk with volume discounts, tracked centrally, and automatically reclaimed when employees leave or no longer need specific apps. This prevents the “license sprawl” common with traditional software licensing where organizations continue paying for unused seats or lose track of which users have which apps installed.

Common Scenarios

Enterprise IT: Purchase licenses for productivity apps (Microsoft Office, Adobe Creative Cloud), collaboration tools (Slack, Zoom), or industry-specific software (AutoCAD, Epic Haiku for healthcare) and silently deploy them to the appropriate user groups. Revoke licenses when employees transition roles or leave the company, then reassign those licenses to new hires without additional procurement delays.

MSP: Manage VPP licenses across multiple client organizations by maintaining separate ABM/ASM accounts per client or using reseller APIs. Deploy standard productivity tools to all client devices while tracking per-client license consumption and costs. Particularly valuable for recurring service contracts where app costs can be billed back to clients based on actual license usage.

Education: Deploy educational apps (GarageBand, iMovie, Swift Playgrounds) to student devices without requiring students to have Apple IDs or make purchases. Use device-based assignment to allocate licenses to shared iPad carts that rotate between classrooms, ensuring licenses follow the device rather than individual students who may graduate or transfer schools.

In Addigy

Addigy integrates with Apple Business Manager and Apple School Manager through VPP location tokens to manage app licenses. Admins upload their VPP token in Addigy’s Apple Apps section, which then syncs available apps and licenses. From there, apps can be deployed to devices or users with automatic license assignment and revocation. Addigy supports both device-based and user-based VPP assignment, tracks license consumption across the fleet, and alerts admins when licenses are running low. Addigy also handles automatic license revocation when devices are unenrolled or when apps are removed from policy assignments.

Stores digital cards and IDs. In MDM, Wallet can be restricted or managed to prevent unauthorized payment methods or deploy corporate access passes.

What to Know

Wallet restrictions prevent users from adding personal payment cards to corporate devices while still allowing organizations to deploy corporate access badges, transit passes, or event tickets. Blocking Wallet entirely prevents both payment functionality and useful business applications like building access cards, so organizations typically restrict payment card additions while allowing corporate-issued passes. MDM also enables remote deployment of Wallet passes, allowing IT to push employee badges, conference tickets, or boarding passes without requiring manual installation.

Common Scenarios

Enterprise IT: Corporate IT restricts Apple Pay card additions on company-owned devices to prevent personal payments while using Wallet to deploy corporate building access badges, employee ID cards, or event passes. IT pushes Wallet passes through MDM for company-wide events, facility access, or transit benefits. On shared devices like retail kiosks or field service iPads, IT typically disables Wallet entirely to prevent any personal use.

MSP: MSPs configure Wallet restrictions based on client policies around personal device use. Most clients restrict payment card additions by default while allowing corporate passes. MSPs should clarify whether clients want to deploy corporate passes through Wallet (building access, transit, etc.) before completely disabling the feature. Some retail or hospitality clients use Wallet to deploy employee badges or shift credentials.

Education: Schools restrict Wallet on student devices to prevent unauthorized purchases and eliminate the risk of students using school-issued devices for personal transactions. Schools may use Wallet to deploy student ID cards for library access, cafeteria payments, or campus building entry. Teacher devices may allow Wallet for personal use if the school permits personal use of teacher-assigned devices.

In Addigy

Addigy’s Restrictions payload includes separate controls for “Allow Wallet” (completely disables Wallet) and “Allow Apple Pay” (disables payment functionality while allowing passes). This granularity allows admins to block payments while still deploying corporate passes. Addigy supports deploying Wallet passes through configuration profiles, pushing corporate badges, tickets, or credentials to devices without user intervention. The Restrictions interface clearly distinguishes between full Wallet disablement and payment-only restrictions.

Webhooks are user-defined HTTP callbacks. In MDM environments, webhooks enable real-time integrations and automation by sending data to other applications when specific events occur (like enrollment completion or compliance failures).

What to Know

Webhooks enable event-driven automation by pushing notifications to external systems the moment events occur in MDM, eliminating polling delays and enabling real-time responses. When devices enroll, fall out of compliance, or trigger security alerts, webhooks can immediately notify ticketing systems, alerting platforms, or custom automation scripts. This enables organizations to build sophisticated workflows that span multiple systems — automatically creating help desk tickets for lost devices, triggering identity system updates when devices are assigned to users, or alerting security teams when devices detect threats.

Unlike traditional API integrations where external systems must constantly poll for updates, webhooks push data proactively, reducing API call volumes and enabling instant reactions to events. Webhook payloads typically contain JSON data describing the event, allowing receiving systems to parse and act on the information. Webhooks support loosely-coupled integrations where systems remain independent but exchange data as needed, enabling flexible ecosystem architectures that adapt to changing requirements without tightly-bound dependencies.

Common Scenarios

Enterprise IT: Corporate IT configures webhooks to send device enrollment notifications to ticketing systems, automatically creating onboarding tickets when new devices appear in MDM. Compliance violation webhooks trigger automated responses like disabling network access or alerting security teams. IT builds custom webhook receivers that parse MDM event data and trigger actions in HR systems, asset databases, or security information and event management (SIEM) platforms. Webhook authentication ensures only legitimate MDM notifications are accepted, preventing spoofing attacks.

MSP: MSPs leverage webhooks to integrate client MDM instances with PSA tools, automatically creating tickets when devices require attention. Webhook-driven automation enables MSPs to provide proactive support — detecting and responding to issues before clients report them. MSP monitoring dashboards aggregate webhook events across multiple client accounts, providing unified visibility into fleet health. Webhooks enable MSPs to build differentiated service offerings through custom automation that competitors lack.

Education: School districts use webhooks to integrate MDM with student information systems, automatically updating device assignments when students change schools or graduate. Webhooks notify help desk systems when classroom device issues occur, enabling rapid support responses during instruction. Education IT can build custom automations triggered by webhooks that enforce policies like automatically checking in shared iPads at day end or alerting when student devices access inappropriate content.

In Addigy

Addigy provides webhook capabilities that enable admins to configure HTTP callbacks for various MDM events including device enrollment, compliance state changes, command execution, and alert triggers. Administrators configure webhook endpoints through the Addigy console, specifying the destination URL, authentication credentials, and which events trigger webhooks. Addigy sends JSON payloads containing event details to configured endpoints in real-time as events occur.

Addigy’s webhook implementation includes retry logic for handling transient failures, payload signing for verifying authenticity, and configurable filters to limit which events trigger notifications. Organizations can build custom integrations by creating webhook receivers that parse Addigy event data and trigger appropriate actions in external systems. Addigy’s API documentation includes webhook payload schemas and examples, helping developers build robust integrations. Webhook activity logs provide visibility into delivery status, helping troubleshoot integration issues.

Payload that configures wireless network connections and authentication (WPA2/3, 802.1X). Can reference certificate payloads for enterprise authentication.

What to Know

Wi-Fi payloads automate network configuration, ensuring devices connect to approved corporate networks immediately upon enrollment without users manually entering complex security credentials or advanced settings. This eliminates configuration errors, reduces help desk tickets, and prevents users from connecting to untrusted networks by pre-configuring preferred networks. Enterprise Wi-Fi networks often use certificate-based authentication and complex security protocols that are difficult for users to configure manually, making automated deployment essential.

Wi-Fi payloads also enable advanced configurations including proxy settings for content filtering, captive network detection, and auto-join behaviors that ensure devices remain connected to corporate networks. From a security perspective, MDM-deployed Wi-Fi profiles can be configured to prevent user modification, ensuring security settings remain intact.

Common Scenarios

Enterprise IT: Deploying 802.1X Wi-Fi configurations with certificate-based authentication across office locations. IT pushes Wi-Fi profiles during enrollment so devices automatically connect to corporate networks when in range, eliminating manual configuration and improving the new hire onboarding experience.

MSP: Managing Wi-Fi configurations for clients across multiple office locations, each with unique SSIDs and authentication requirements. MSPs use scoped profiles to ensure devices connect to appropriate networks based on location while maintaining centralized configuration management.

Education: Deploying campus Wi-Fi profiles to student and faculty devices with appropriate access levels and content filtering proxies. Schools configure auto-join for campus networks while preventing connection to unauthorized personal hotspots or guest networks during instructional time.

In Addigy

Addigy’s Wi-Fi payload configuration supports all standard security protocols including WPA2/WPA3 Enterprise, certificate-based authentication via SCEP, and proxy settings for filtered environments. Addigy validates Wi-Fi configurations before deployment and can bundle Wi-Fi profiles with certificate payloads to ensure seamless authenticated network access.

Addigy provides Wi-Fi profile templates for common enterprise configurations and displays Wi-Fi connection status in device inventory. When troubleshooting connectivity issues, admins can view Wi-Fi profile installation status and deployment logs to identify configuration problems or authentication failures.

X.509 is an international standard for the format of public key certificates. In MDM, X.509 certificates are used for HTTPS server authentication, client authentication (for Wi-Fi/VPN), APNs push notification authorization, and code signing.

What to Know

X.509 certificates are the foundation of trust in digital communications, binding public keys to identities through cryptographic signatures from trusted certificate authorities. Every HTTPS connection, including all MDM traffic, relies on X.509 server certificates to verify server identity and prevent man-in-the-middle attacks. Client certificates enable strong authentication for network access (802.1X Wi-Fi, VPN) without passwords, improving security while reducing credential management overhead. Certificate-based authentication also enables automated authentication for devices and services without human intervention.

X.509’s hierarchical trust model allows organizations to issue certificates from internal CAs while maintaining trust through root certificates installed on devices. Certificate fields (subject name, validity period, key usage) constrain how certificates can be used, preventing misuse. However, certificate lifecycle management is critical — expired certificates break connectivity, revoked certificates must be checked via OCSP or CRLs, and private key compromise requires immediate certificate revocation and reissuance. Organizations must track certificate expiration across all systems and implement automated renewal processes to prevent outages.

Common Scenarios

Enterprise IT: Corporate MDM servers present X.509 certificates for HTTPS authentication, with IT monitoring expiration dates and coordinating renewals before certificates expire. Client certificates are deployed via MDM for 802.1X Wi-Fi authentication and VPN access, enabling password-less network access with certificate-based authentication. IT must maintain certificate infrastructure (internal CA or public CA relationships), track certificate inventory across the estate, and implement certificate revocation procedures for compromised or retired devices. APNs certificates require annual renewal, with strict attention to expiration dates as there is no grace period.

MSP: MSPs manage certificate lifecycles for hosted MDM infrastructure and client-deployed certificates, implementing automated renewal workflows to prevent certificate expiration outages. Multi-client deployments require tracking certificates across diverse client environments, with different CAs, validity periods, and renewal schedules per client. MSPs should implement certificate expiration monitoring with proactive alerts 30-60 days before expiration, providing sufficient time for renewal coordination with clients. Certificate deployment automation via MDM profiles eliminates manual certificate distribution to individual devices.

Education: School districts deploy X.509 certificates for student device Wi-Fi authentication, typically issuing per-device certificates that identify individual devices on the network. Education IT must balance certificate validity periods (longer periods reduce renewal frequency, shorter periods limit compromise exposure) with operational capabilities for certificate renewal and redistribution. Public CA certificates for MDM servers simplify deployment by eliminating internal CA root certificate distribution to BYOD devices. Certificate-based authentication eliminates Wi-Fi password sharing among students while enabling network access control.

In Addigy

Addigy’s cloud infrastructure uses industry-standard X.509 certificates trusted by all Apple devices, with automatic certificate lifecycle management handled by Addigy. Administrators can deploy X.509 client certificates to managed devices through PKCS#12 certificate profiles or SCEP automatic enrollment, enabling certificate-based authentication for Wi-Fi, VPN, and applications. Addigy supports deploying trusted root certificates to establish trust for internal CAs or specific services.

Addigy tracks deployed certificate expiration dates and provides visibility into certificate status across the managed fleet, helping admins identify devices with approaching certificate expiration. Addigy’s APNs certificate management includes expiration notifications and guided renewal workflows, preventing service disruptions from expired APNs certificates. When troubleshooting certificate-related issues, Addigy support can analyze certificate validation errors and help admins identify trust chain problems, expiration issues, or hostname mismatches causing connectivity failures.

XML is a markup language defining rules for encoding documents. In MDM and Apple management, XML plays a critical role through the Property List (plist) format. MDM communication uses XML-formatted plists for command requests and responses, and configuration profiles are XML documents.

What to Know

XML provides the structured data format for virtually all Apple configuration and management operations. MDM profiles (.mobileconfig files) are XML documents defining device configurations, from Wi-Fi settings to security restrictions. The MDM Protocol uses XML-formatted plists for all command-response communication between servers and devices. macOS and iOS applications store preferences as XML plists, and system configurations often rely on plist files. Understanding XML structure helps admins troubleshoot profile deployment issues, customize configuration profiles, and interpret MDM protocol logs.

XML’s self-describing hierarchical structure makes configurations human-readable while remaining machine-parseable. XML validation ensures profiles are syntactically correct before deployment, catching errors that would cause installation failures. However, XML’s verbosity makes it less efficient than binary formats, and manual XML editing is error-prone — a single syntax error (unclosed tag, incorrect nesting) renders entire profiles invalid. Profile tools and MDM platforms abstract XML complexity, generating valid XML from administrator inputs, but troubleshooting sometimes requires examining raw XML to identify issues.

Common Scenarios

Enterprise IT: IT admins occasionally need to inspect or manually edit configuration profile XML to implement settings not exposed through MDM console interfaces. Custom profiles for specialized applications may require hand-editing XML payloads referencing Apple documentation. When profiles fail to install, examining XML syntax helps identify malformed tags, incorrect payload identifiers, or incompatible value types. IT should use XML validation tools before deploying hand-edited profiles to catch syntax errors that would cause deployment failures.

MSP: MSPs building standardized configuration templates may create master XML profiles that are customized per client through text replacement or XML parsing scripts. Understanding XML structure enables MSPs to template common configurations while varying client-specific details (Wi-Fi SSIDs, server addresses, organization identifiers). MSPs troubleshooting profile deployment failures across clients should examine XML differences between working and failing configurations to identify syntax or content issues causing problems.

Education: Education IT departments deploying profiles across thousands of devices must ensure XML syntax is correct to avoid mass deployment failures. Custom profiles for education-specific applications (learning management systems, content filters, student information systems) often require XML editing to configure application-specific settings not available through standard MDM interfaces. Education IT should maintain version-controlled repositories of profile XML to track changes over time and enable rollback if configurations cause unexpected behavior.

In Addigy

Addigy’s platform generates valid XML configuration profiles automatically from administrator inputs through the admin console interface, eliminating manual XML editing for standard profile types. For custom profiles requiring specialized XML payloads, admins can upload hand-crafted XML profiles or use Addigy’s custom profile tools to define XML payload structures. Addigy validates XML syntax before deployment, catching malformed profiles that would fail installation on devices.

When troubleshooting profile installation failures, Addigy support can examine profile XML to identify syntax errors, payload conflicts, or incompatible settings causing issues. Addigy provides visibility into profile deployment status at the XML payload level, helping identify which specific profile sections are failing to apply. Addigy’s device logs include MDM protocol communication showing XML-formatted commands and responses, enabling deep troubleshooting of device-server communication issues when standard diagnostics don’t reveal the root cause.

Apple’s built-in signature-based malware detection system for macOS. Scans files automatically in the background.

What to Know

XProtect provides baseline malware protection for all Macs without requiring third-party antivirus software. It automatically scans downloaded files for known malware signatures and blocks execution when threats are detected. Unlike traditional antivirus products, XProtect updates silently in the background via system data files, requiring no user action or MDM deployment. This ensures even unmanaged Macs receive protection against newly discovered threats.

For enterprises, XProtect serves as a security baseline, though many organizations layer additional endpoint protection solutions on top of it. Understanding XProtect’s capabilities helps IT teams avoid redundant security controls while ensuring adequate protection. XProtect focuses on prevalent Mac malware and adware, making it most effective against common threats rather than sophisticated targeted attacks.

Common Scenarios

Enterprise IT: XProtect runs automatically on corporate Macs, providing baseline protection that requires no management overhead. IT teams layer enterprise endpoint protection solutions (CrowdStrike, SentinelOne, etc.) on top of XProtect for behavioral analysis, threat hunting, and advanced detection capabilities that XProtect doesn’t provide.

MSP: For smaller clients or those with limited security budgets, MSPs may rely on XProtect as the primary malware protection, supplemented by content filtering and email security solutions. MSPs educate clients that XProtect is signature-based only and doesn’t provide real-time behavioral monitoring or advanced threat protection.

Education: Schools benefit from XProtect’s automatic protection on student devices without deployment complexity. Combined with content filtering and supervised restrictions, XProtect helps protect against malicious downloads while minimizing IT overhead for managing antivirus software across large device fleets.

In Addigy

Addigy does not manage XProtect directly (it’s a built-in macOS component that updates automatically), but admins can view XProtect version information in device inventory to verify devices are receiving updates. Addigy can deploy additional endpoint protection solutions that complement XProtect’s capabilities, and reporting tools can track malware detection events if third-party solutions integrate with Addigy’s platform.

A deployment methodology where devices are automatically enrolled, configured, and provisioned without requiring manual IT intervention, leveraging Automated Device Enrollment.

What to Know

Zero-touch deployment represents the pinnacle of modern device management efficiency, enabling organizations to ship devices directly from Apple or resellers to end users without IT ever physically handling them. Using Automated Device Enrollment, pre-stage configurations, and automated policy deployment, devices arrive at users’ doorsteps, power on, and automatically configure themselves with all necessary apps, settings, and security policies. This eliminates the traditional staging and imaging processes that once required dedicated IT staff and physical device handling, dramatically reducing deployment costs and time-to-productivity.

Zero-touch deployment is especially critical for distributed workforces, rapid scaling scenarios, and organizations with limited IT resources. It enables true work-from-anywhere strategies by allowing employees anywhere in the world to receive and activate devices without visiting an office or waiting for IT support. The methodology also improves security by ensuring devices are managed from first boot, preventing the window of vulnerability that exists when devices are shipped unmanaged and manually enrolled later.

Common Scenarios

Enterprise IT: A company hiring 500 remote employees orders MacBooks through Apple Business Manager, assigns serial numbers to Addigy, and configures pre-stage profiles. Devices ship directly to employees’ homes. New hires power on their MacBooks, complete minimal Setup Assistant steps, and find all corporate apps, VPN, and security policies pre-installed. IT never touches the hardware, and employees are productive within hours of receiving their devices.

MSP: An MSP onboards a new client requiring immediate device deployment across 20 locations. The MSP orders devices through their Apple reseller, assigns serial numbers to the client’s MDM instance, and configures location-specific pre-stages. Devices ship to each location, and local staff follow simple power-on instructions. The MSP monitors enrollment remotely, and all devices are fully configured without the MSP visiting any client sites.

Education: A school district deploys 10,000 iPads for a 1:1 student program. Devices are assigned to Apple School Manager, pre-configured with grade-level apps and restrictions, and shipped directly to students’ homes during summer break. Students unbox and activate iPads at home, and they’re immediately ready for remote learning. IT accomplishes in weeks what would have taken months of manual staging.

In Addigy

Addigy enables complete zero-touch deployment through its Automated Device Enrollment integration and priority deployment policies. You configure pre-stage profiles that skip Setup Assistant screens, define initial policies, and specify which apps install automatically during first boot. When devices power on and connect to the internet, they automatically enroll in Addigy, download assigned policies, and install required apps without user interaction.

Addigy’s await configuration option ensures devices don’t proceed past Setup Assistant until all priority policies and apps have installed, preventing users from accessing incompletely configured devices. You can monitor zero-touch deployment progress in real-time through Addigy’s enrollment dashboard, viewing which devices have completed enrollment, which are in progress, and troubleshooting any that encounter issues—all without physically accessing any hardware.