One Mac, One Admin Password: How We're Rolling Out macOS LAPS with Iru

Every Mac we manage has a local administrator account on it that belongs to us. It isn’t the account you sign into each morning. It’s a separate account our engineers use when something needs fixing at the lowest level: a stuck update, a recovery, a machine that has decided it no longer wants to take a policy. That account has a password, and for a long time the honest answer to “where does that password live and how often does it change?” has been more awkward than anyone in IT likes to admit.

Iru just fixed that for macOS, and we’ve started rolling it out across the fleets we manage. This post covers what changed, how it works, and what it means for you (short version: better security on our side, and nothing you’ll notice on yours).

The Quiet Problem with Local Admin Passwords

The traditional approach to local admin accounts on a fleet of Macs goes something like this. Pick a strong password. Set it on every machine. Store it in a shared vault. Change it when someone remembers to, which in practice means when someone leaves or when an audit asks about it.

The trouble is what that password represents. It’s the same credential on every device. If it leaks from one machine, through a keylogger, a screenshot, a support session, or an old sticky note, it unlocks all of them. An attacker who gets that far doesn’t need to break anything else. They just move from Mac to Mac with the key you handed them.

There’s also the people problem. Anyone who has ever worked on your fleet, whether a former employee, a contractor, or a previous IT vendor, may still know that password. Rotating it properly means touching every device, so it tends not to happen.

None of this is unique to Apple environments. Windows had the exact same issue, which is why Microsoft introduced a fix for it years ago.

What LAPS Actually Is

LAPS stands for Local Administrator Password Solution. Microsoft shipped the original version for Windows in 2015, and the idea behind it is refreshingly simple:

Every device gets its own randomly generated local admin password. No two machines share one.
Those passwords rotate automatically on a schedule, so none of them stay valid for long.
The current password for each device is stored (escrowed) securely in the management system, not in a spreadsheet or a shared vault.
When a technician needs the password for a specific machine, they retrieve it through the management console, and that retrieval is logged.

Do that, and a leaked admin password is worth one machine, for a limited window, with a record of who last looked at it. That’s a very different risk profile from one password that opens everything forever.

Apple environments have never had a clean, native equivalent. Apple added an MDM command a few years back that can set a managed admin password, but it comes with enough limitations that most Mac admins have either built their own scripts or simply lived with the shared-password approach. That’s the gap Iru just closed.

How Iru Implements It

Iru’s macOS LAPS is a new Library Item, which in Iru terms means it’s a policy you define once and assign to the devices it should cover. From there, the platform handles the rest:

Unique, strong passwords on every Mac. You set the length and complexity rules once, and every device generates its own password that meets them.
Automatic rotation. Passwords rotate on a cadence you choose, so a credential never stays valid indefinitely.
Rotation after someone looks at it. When an authorized person retrieves a password, Iru schedules a rotation shortly after. The password you were shown is retired automatically, and looking at it a second time doesn’t extend that window.
Secure escrow. Passwords are encrypted in transit and at rest using the same architecture Iru uses for other secrets it manages.
Verified access. The Iru agent confirms the new password actually works on the device and was successfully stored before it reports success. The password you see in the console is a working password, not a hopeful one.
Role-based retrieval. Only people with the right role in Iru can view a password at all.
A full audit trail. Every configuration change, rotation, and retrieval is recorded: who, which device, and when.

For the technically curious

Iru made an interesting design choice here. Rather than relying on Apple’s built-in MDM command, they implemented LAPS through the Iru agent that already runs on every managed Mac.

That matters because changing an admin password on a modern Mac is not as simple as overwriting a string. On Apple silicon, admin accounts carry SecureToken and Volume Ownership, which are what allow the account to unlock FileVault and authorize things like OS updates. If you reset the password blindly, you can end up with an admin account that technically has a new password but has lost the authorization that made it useful in the first place. macOS requires the existing credential during the change to keep that chain intact.

The Iru agent handles this as a proper transaction using native Open Directory APIs: it supplies the current password, applies the new one, verifies the change took, and reports status back to Iru. If macOS rejects the change for any reason, the failure is reported so it can be retried and investigated rather than silently leaving a device in a bad state. It’s a small detail with large consequences, and it’s the kind of thing that separates a LAPS implementation that works from one that looks like it works.

How We’re Rolling It Out

Iru is the device management platform we use for every Apple environment we support, so this isn’t a new tool we’re asking anyone to adopt. It’s a capability we’re switching on inside the platform that’s already managing your Macs.

The scope is worth being clear about. This rollout covers the administrator account that 2Fifteen Tech places on each Mac we manage, the one our engineers use when we need to support a machine. It does not touch your accounts. Your user accounts, your passwords, and any admin accounts your own team maintains stay exactly as they are. This is a change to how we secure our own access to your devices, not a change to how you use them.

Here’s what we’re doing:

Our admin account on every Mac gets its own password. Instead of one credential that our team could use across many machines, each device gets a unique one that only works there.
Rotation happens on a schedule, and again after any retrieval. If one of our engineers pulls a password to fix something, that password is retired shortly after the job is done.
Retrieval is limited to our engineers and logged every time. When we need to get into a machine at the admin level, there’s a record tying that access to a specific person and a specific device.
Nothing changes on your side. You won’t be prompted, nothing on your Mac will look different, and no one on your team needs to do anything. The only thing that changes is what happens behind the scenes when we step in to help.

We’re working through customer fleets in stages, verifying each rollout as we go. If you’re an existing customer and want to know where your environment is in that process, ask us and we’ll tell you.

What You Get Out of It

The benefit to you is mostly about what no longer happens.

A compromised Mac stays a compromised Mac. If an attacker ever got hold of our admin credential on one machine, it would no longer open any other machine in your fleet, and it would stop working shortly after anyway.

Vendor access gets cleaner. When someone on our side stops working on your environment, there’s no shared password to hunt down and change on every Mac. Anything they may have seen has already rotated. That’s the standard you should hold any IT provider to, and it’s one we can now demonstrate rather than just describe.

Audits and insurance questionnaires get easier. “Does your IT provider use unique admin credentials per device, with rotation and access logging?” is a question that shows up in SOC 2 work, cyber insurance applications, and vendor security reviews. The answer is now yes, with the evidence to back it up.

And there’s nothing new to buy, install, or learn. It runs inside the platform we already manage for you.

A Few Questions We Expect

Will I need to do anything? No. The rollout happens through Iru, and it doesn’t affect your user account, your password, your files, or how you sign in.

Are you changing passwords on my team’s accounts? No. This only applies to the 2Fifteen Tech admin account on each Mac. If you have your own local admin accounts, they’re untouched. If you’d like to extend LAPS to those accounts down the road, it’s something we can talk through, but it isn’t part of this rollout.

What if one of us needs admin access on a Mac? Reach out to us like you do today. Nothing about that process changes.

Does this replace FileVault, MFA, or the other security controls on my Macs? No. It sits alongside them. LAPS closes one specific gap: the shared, rarely rotated admin password that most fleets have been carrying for years.

Does this apply to iPhones and iPads? No. Those devices don’t have local administrator accounts in the same sense, so LAPS is a Mac-specific control.

The Bigger Picture

Most security improvements come with a tradeoff. Something gets harder for users, or slower for IT, or more expensive for the business. This one is rare in that it makes things meaningfully safer while asking nothing of the people using the devices.

As an Iru partner, we get to put changes like this to work across every environment we manage as soon as they land. If you’d like to talk about how your Macs are being managed today, or whether there are gaps like this one still open in your fleet, we’re glad to walk through it.