By the Numbers: Enforcing Password Policies on Apple Devices

IT admins naturally care about the passcodes their users choose to unlock their Apple devices. 

That’s partly because the passcode is one of the first and best lines of defense for those devices. But it's a line of defense that depends on users. Admins can set minimum requirements for those passcodes and specify when they’re required. However, the choice of the passcode itself is up to the user. 

(A word on nomenclature: Traditionally, a password was tied to a user or account name, while a passcode was tied to a device. That's why Apple's Platform Security Guide distinguishes between passwords for Mac computers and passcodes for iPhone and iPad devices. But, for the sake of simplicity, because Kandji has a Passcode Library Item that can be used to define requirements for passwords on Mac as well as passcodes on iPhone and iPad endpoints, we'll refer to “passcodes” throughout this post.)

As an admin, you might naturally think that the best passcodes are the longest and most complex. Those two factors certainly define the difficulty of cracking them. But they also make the resulting passcodes harder to use. And if you require passcodes that are hard to use, users resort to things like writing them down—which obviously doesn’t help protect your devices.

So what is the best way to balance security and usability? As usual, it depends on context. Here’s how we’d think it through, along with some insights into how real-world IT admins manage passcodes in their environments.

What Is a Passcode Policy?

As an IT admin, you have a few levers to pull when it comes to enforcing good passcode hygiene. Ideally, most of those levers can be found in your MDM solution.

Note: if you’ve set up a system (such as Kandji Passport) to keep your local Mac account password in sync with your cloud identity provider account password, we recommend that you set your passcode policy at the IdP, not in your MDM solution. This exception applies to Mac only.

Passcode Length and Complexity

You’ve no doubt seen charts showing how long it’d theoretically take a bad actor to discover passcodes of varying lengths and complexity using brute force. By some calculations, a 12-character passcode consisting of nothing but numbers would take 25 seconds to crack, whereas a 12-character passcode combining upper- and lowercase letters, numbers, and typographical symbols would take 34,000 years.

That might make you think that complexity is the key. Indeed, a passcode combining 9 lower and upper letters offers the same challenge to hackers as one that consists of 12 lower-case letters. Adding numbers helps that much more. 

Requiring complex characters can help, too; some compliance regimes (such as CIS) demand them. But in terms of mechanically hacking a passcode, a semicolon or dash is just another character; it alters the math a bit, but not as much as adding length: A combination of 11 alphanumeric and complex characters offers roughly the same degree of difficulty to a hacker as 14 upper- and lowercase letters.

The downside of complex characters is that they make passcodes harder for users to remember than it does for attackers to guess. Humans are pretty good at remembering sequences of numbers and letters; punctuation marks, not so much. 

We’re particularly good at remembering sequences of words. That’s why one favored strategy is using a sequence of three or four words. That way, you get longer passcodes that maximize both memorability and entropy (the measure of a passcode’s randomness). If any of your users speak multiple languages, they can use that to their advantage, by including words not in their daily language.

Long passcodes have the added advantage of being resistant to shoulder-surfing spies. That makes them particularly good for retail services—think banking or insurance offices—where users must use assigned computers in public. 

When Is Passcode Required?

Length and complexity are just two components of a passcode policy. You should consider several others.

The first: When should a passcode be required? Specifically, how long after sleep or the screensaver begins must a user supply a passcode? Your MDM solution should provide a range of options; Kandji, for example, lets you specify any time gap from 0 minutes (in other words, the user will always be prompted for a passcode whenever the device goes to sleep or the screensaver launches) to 8 hours. Here's how Kandji customers configure that setting:

This is another time you should take into account how accessible the device is to unauthorized users. If it’s in a private office that nobody comes into unbidden, you might not need to require a passcode immediately. If it’s on a desktop that many people can access, you’d want to require a passcode after a short period of inactivity.

This setting is also connected to how soon the screensaver launches or sleep initiates; you should be able to control both via MDM. Here's how Kandji customers have configured it:

How Often to Change Passcode?

Another factor: How often must the passcode be changed? Passcode expiration is specifically designed to combat social engineering. Most MDM solutions provide tools to define maximum passcode ages; in Kandji, for example, you can require users to change their passcodes anywhere from daily to every two years. 

But, again, the more rigorous you are about this, the more of an onus you’re putting on users. Can they really come up with new strong but memorable passcodes as often as you want them to? Changing them frequently—monthly or more often—makes sense only in settings with the strictest security requirements. Anything less than once a year could be overkill in many circumstances.

The Consequences of Errors

One final consideration to include in your passcode policy decision is the consequences of entering a passcode incorrectly. Ideally, your MDM solution allows you to set a maximum number of failed attempts before the user is locked out of their device. Here's how Kandi customers have configured that option:

You should be especially careful on this one, because you have to consider the impact of locking a user out of their device. Mistyping a passcode or other errant passcode entries—a child mashing the keypad on your iPhone for fun, say—can happen to anyone. So, how easy do you want to make it for users to be locked out? 

If users already have a long passcode by policy (perhaps to foil those shoulder surfers), are three failed passcode entries a good trigger for lockout? Can you be more or less lax, based on your threat modeling for this situation? 

By Apple’s design, if a user enters the wrong passcode on an iPhone or iPad six times in a row, they’ll be locked out of the device. If the passcode is actually forgotten, you could, as an admin, remotely remove the passcode via MDM.

That’s assuming the device remains online. Often, users facing a passcode problem will try to restart their device, hoping this will reset the counter. (It does not.) Now the device can’t access Wi-Fi; because of the way iOS and iPadOS store Wi-Fi credentials, the passcode must be entered after a reboot before the device joins Wi-Fi. (Those credentials are stored with the Protected Until First User Authentication Data Protection Class.) A cellular connection can help here, as it is always active even when Wi-Fi isn’t.

In most such scenarios, the result is that the user—or you, as an admin—will have put the device into recovery mode, which erases all user content and sets up the device from scratch. Even worse: If your setting for maximum failed passcode attempts is low enough, the device will be erased immediately. That means there’s no chance for you to assist the user before their data is erased. So consider setting the maximum number of failed attempts high enough to avoid innocuous scenarios, while keeping within the bounds of your security policies.

Best Practices for Passcode Policies  

Those passcode settings are just part of the equation in creating a passcode policy. You also need to consider several real-world factors.

Who’s Using the Device?

Different users—and their different usage patterns—dictate different passcode policies. 

For example, a retail clerk using an iPhone to look up product inventory or a warehouse worker using one to scan barcodes probably shouldn’t be asked to enter a six-digit passcode every time they pull the device from its holster. (Particularly because they might be holding something else in their other hand, meaning they have to enter passcodes with their thumbs.) 

On the other hand, a mobile executive who uses their phone for sensitive communications on the road is going to need a robust passcode that needs to be periodically reentered. 

In both cases, allowing FaceID or TouchID can help.

What About Biometrics?

Speaking of which, Face ID and Touch ID both allow users to log in without passcodes—which is great for single-user devices. But even with biometrics in place, the user will still need to enter a passcode when:

• They restart their iPhone, iPad, or Mac;
• More than 48 hours have passed since they last unlocked the device;
• (In the case of Face ID) the passcode hasn’t been used in the last six and a half days, and Face ID hasn't unlocked the device in the last 4 hours;
• They want to update their Touch ID or Face ID settings; or
• There have been more than five failed Touch ID or Face ID attempts in a row.

The availability of biometrics can offset the more onerous passcode policies, but users will still have to follow them at least occasionally.

Where Is It Being Used?

As we’ve already noted, the physical context—in particular, the degree of access to the location by people who are not authorized to use the device—makes a big difference. 

If the device is going to be used in a closed environment, such as a factory, random people won’t be wandering around poking at people’s phones. In retail, everybody might have access. The level of security you impose on the device should be directly proportionate to the level of access to it and what data is allowed to reside on it.

What’s at Risk?

You need to calibrate your passcode policy to the sensitivity of the data on the device. If entering a passcode could give a bad actor access to valuable intellectual property, you’ll obviously want to impose stricter passcode requirements. 

On the other hand, if the device itself has little data but can be used to access sensitive corporate data in the cloud, you can add a second layer of authentication and authorization between the device and that data. Ideally, your users have tools on their devices to store the many other passcodes required for SaaS apps and the like.

You can control endpoint security with a passcode, but everything else is protected on the infrastructure level. You can, for example, implement a zero-trust networking architecture so that devices must prove that they’re secure repeatedly to access your most sensitive data. But that doesn’t have to mean making it onerous for users to access their devices.

What Are Your Compliance Requirements?

Finally, you need to connect with your compliance experts to see what kinds of passcode policies they require.

Some compliance regimes simply require your organization to mandate complex passcodes or have a passcode management system in place. That leaves you with some wiggle room. Find out what yours requires and adjust your passcode policy accordingly.

Passcode Use Cases

To see how all those factors can combine in the real world, let’s take a few examples.

Airline Pilot

Airline pilots increasingly use iPad devices as electronic flight bags (EFBs), which carry all the information they need to do their jobs: Checklists, operating manuals, navigational charts, and so on. To a pilot and the airline that employs them, that device is absolutely critical. If it’s inaccessible, the pilot can’t fly, the plane doesn’t take off, and passengers (or shippers) are irate.

Pilots typically take such devices everywhere they go: On the plane, of course, but also throughout the airport, to the hotel, and back home. That means it’s exposed to a variety of unauthorized people. Exposure of the data on the device (which can’t be in the cloud) could present a critical risk to flight safety. So clearly, you want to install rigorous passcode policies on it—with one exception.

Let’s say the pilot takes the iPad home, and their young child starts playing with it. The kid wants to play but can’t, so starts trying to crack it with whatever passcode they can think of. Pretty soon, the device reaches its limit of passcode tries and locks down. In this case, you want to ratchet up the number of allowable passcode attempts and make it as easy as possible for that pilot to recover from too many (by waiting out the deactivated state instead of having to deal with an erased device). 

Warehouse Worker

Let’s consider the case of those warehouse workers we mentioned above, who use iPhones to scan barcodes. They each grab a new device at the beginning of the shift and then turn it in when they’re done; between shifts, the devices are erased. There isn’t much public access to the worksite, so it’s unlikely a bad actor will wander in looking for stray devices.

In that case, you might want to have a relatively simple passcode. If the worker isn’t able to use biometrics to unlock such a shared device, they’ll need a simple four-digit passcode that’s easy to enter multiple times a day. At the same time, you’d use your backend security infrastructure to restrict that device’s ability to reach core intellectual property on the network. The device will do the job it’s intended for, but nothing more.

Retail Worker

Finally, let’s think of the case of an optician working in a retail environment. They might have two or three devices sitting on tables in the store all day, which are shared randomly by multiple workers. 

Because it's a public space, they need to have a passcode on there. But that passcode has to be relatively simple so multiple employees can remember it and pick up any device. In that case, you’d want to consider changing that passcode frequently—perhaps daily. You need good SSO, so the clerks can access networked data from the devices after passing through another layer of authentication.

Managing Passcode Policy with MDM 

As you can see, there’s no one correct answer to the question of what kind of passcode policy you should implement. You need to consider many factors: the kinds of devices, the kinds of users, how and where they use those devices, and the kinds of data made accessible by successfully entering the passcode.

Your policy should be as rigorous as possible without becoming unusable. It should always be a little tough on users, just not so tough that they start looking for workarounds that could potentially put your data in more danger than it would be if you just allowed, say, simple, long passcodes.

There are times when the toughest possible policies are needed, but they shouldn’t be the default. You can't just check all the boxes, drag the sliders to the right, and call it a day. You need to find a balanced approach. 

About Kandji

Kandji is the Apple device management and security platform that empowers secure and productive global work. With Kandji, Apple devices transform themselves into enterprise-ready endpoints, with all the right apps, settings, and security systems in place. Through advanced automation and thoughtful experiences, we’re bringing much-needed harmony to the way IT, InfoSec, and Apple device users work today and tomorrow.