Why Iru Isn't Just Another MDM: The Ideas That Make It Different
Most MDM platforms were built to solve one problem: managing devices. They do that job well enough, and over time they’ve added features (security modules, patching tools, compliance reports) to keep up with what IT teams need. But at their core, they’re still device management tools with extras bolted on.
Iru started from a different premise. It was designed as a unified platform where identity, endpoint management, endpoint security, and compliance all share the same foundation. That sounds like a small distinction, but it shapes almost everything about how the platform works.
As an Iru partner, we’ve deployed it across dozens of organizations. Here’s what that different starting point actually means in practice.
Platform Architecture vs. Feature Accumulation
Traditional MDM solutions grow by adding features to a device management core. Need EDR? Here’s an add-on. Need compliance reporting? Here’s another module. Need identity management? Integrate with a third-party provider.
The result is a collection of capabilities that technically exist under one vendor’s umbrella but don’t truly share context. Your EDR tool might flag a device as compromised, but your MDM console doesn’t automatically adjust that device’s access to company applications. Your compliance module might show a policy gap, but it can’t pull evidence directly from the endpoint management layer because they were built as separate systems.
Iru’s approach is different by design. Every product (endpoint management, endpoint detection and response, vulnerability management, workforce identity, compliance automation, and trust center) was built on a shared data layer called the Iru Context Model. It’s a living map of your environment: devices, users, apps, policies, posture signals, events, and actions.
When products share real context instead of passing data through integrations, the outcomes change. A security event on an endpoint can immediately inform an identity decision. A compliance control can pull live evidence from devices without anyone manually collecting screenshots. The platform knows what’s happening across the stack because the stack is actually one system, not several systems wearing a trenchcoat.
Built for Apple First
Most MDM platforms started life as Windows management tools. The Apple features work, but they’re translations of Windows-centric concepts. The interface reflects Windows management paradigms. The automation logic follows patterns that make more sense for Group Policy than for Apple’s MDM framework.
Iru (originally Kandji) was built from the ground up for Apple. Every design decision, automation workflow, and management paradigm was created with macOS, iOS, iPadOS, and tvOS as the primary target. Apple’s MDM framework, Apple Business Manager integration, and the Apple ecosystem’s unique characteristics aren’t afterthoughts. They’re the foundation.
This shows up in practical ways. Zero-touch deployment through Apple Business Manager works the way Apple intended. OS update enforcement uses Apple’s native Declarative Device Management (DDM) protocol. Configuration profiles are built around how Apple devices actually work, not adapted from a Windows management model.
The platform has since expanded to include Windows and Android. But the Apple-first heritage means organizations running Apple environments get a platform designed for how they work, not one that’s been retrofit to accommodate them.
Automation Is the Default
Most MDM platforms offer automation as a feature. You can create a rule, set a trigger, and have something happen automatically. That’s useful, but it’s automation layered on top of a platform that was designed for manual administration.
Iru was designed around automation from the start. The operating assumption is that devices should stay in their desired state without ongoing manual intervention.
Assignment Maps are a clear example. Instead of flat, static group-based policies (create a group, assign a policy to the group, manage group membership manually), Iru uses a visual, logic-driven approach. You map out configurations, apps, and security controls with conditional logic. If a device meets these criteria, it gets this configuration. No manual group management. No remembering to move a device when someone changes departments.
Auto Apps is another example. With over 200 common business applications in a maintained library, Iru handles deployment and patching automatically. You set the app and the enforcement schedule. The platform handles versioning, prompts users for convenient update times, and enforces when deadlines pass. The alternative is manually packaging, deploying, and tracking updates for every application across every device, which is what most MDM platforms still expect.
When the system automatically maintains device configurations, patches applications, enrolls new devices through zero-touch deployment, and enforces OS updates, the IT team’s daily workload changes. Instead of spending time maintaining devices, they spend time on strategy and improvements.
Single Agent, Multiple Functions
A common pattern in endpoint management is agent sprawl. One agent for device management. Another for EDR. Another for vulnerability scanning. Maybe a fourth for compliance monitoring. Each agent consumes resources, requires its own updates, and creates its own data silo.
Iru runs a single, lightweight agent that handles endpoint management, endpoint detection and response, and vulnerability management. One installation. One update cycle. One resource footprint. Three critical functions.
This isn’t just a convenience. It changes the security model. When your EDR and your device management share the same agent and the same data, threat detection can immediately trigger device management actions. A detected threat can lead to automatic containment without waiting for two systems to communicate through an integration. Vulnerability findings can prioritize patching through the same agent that handles app updates.
For end users, one agent means less resource consumption and fewer mysterious background processes. For IT teams, it means one thing to deploy, maintain, and troubleshoot instead of managing an agent ecosystem.
Identity as Part of the Platform
Most MDM solutions treat identity as someone else’s problem. They integrate with identity providers (and those integrations work), but the MDM has no native concept of who a user is beyond what the IdP tells it.
Iru includes Workforce Identity as a core platform product: passwordless authentication with device-bound passkeys, single sign-on to every app, and conditional access policies based on real-time device posture. All of it is built into the same platform that manages and secures the device.
That changes what’s possible. When identity and endpoint management share the same data model, access decisions can factor in live device security posture at the moment of sign-in. Is the device encrypted? Is the firewall enabled? Is the OS up to date? These aren’t questions that require an integration to answer. The platform already knows.
The practical benefit is a trust fabric that ties users, devices, and applications together. Access isn’t just “does this person have the right credentials?” It becomes “does this person, on this device, in this security state, have the right to access this application right now?” That evaluation happens automatically, every time.
Compliance as Part of Operations
Compliance has traditionally been a separate workstream from device management. Your MDM manages devices. Your compliance team manages frameworks, evidence collection, and audit preparation. The two groups occasionally coordinate, usually under deadline pressure before an audit.
Iru treats compliance as a continuous, integrated function. Compliance Automation maps your security controls to the frameworks you need to satisfy, then automatically collects evidence from across the platform. Because the compliance layer shares the same data as endpoint management and identity, evidence doesn’t need to be manually gathered. It’s generated as a byproduct of normal operations.
The Adaptive Evidence Map stays current as your environment changes. New devices get enrolled, configurations adjust, security policies evolve, and the evidence map updates to reflect reality instead of a snapshot from three months ago.
For organizations that need to demonstrate compliance with SOC 2, ISO 27001, or other frameworks, this turns audit preparation from a scramble into a standing state. Your Trust Center (a public portal showing your security and compliance posture) can stay current because it’s pulling from live data, not a PDF that was accurate when someone created it.
Why These Differences Matter
None of this is about feature checklists. Any MDM platform worth considering has device management, app deployment, security policies, and patching. The differences are architectural, and they show up in how IT teams spend their time.
With a traditional MDM, IT teams manage devices and then separately manage identity, security, compliance, and a portfolio of integrations that tie those systems together. With Iru, those capabilities operate as one system with shared intelligence. The administrative overhead is different. The security model is different. The daily experience is different.
For organizations that want device management and nothing more, a traditional MDM works fine. But for organizations that see device management as one part of a broader IT and security strategy, and want those pieces to work together instead of alongside each other, the architectural approach matters.
Want to See It in Practice?
At 2Fifteen Tech, we’re an Iru partner that manages Apple environments end to end. If you’re curious about what a unified approach to device management, identity, security, and compliance actually looks like in a real organization, we’re happy to walk through it.