For some admins, device names are crucial to their workflows. It’s the fundamental way they identify specific devices for remote management and in-person service. Admins also build workflows—often involving APIs—using the name as a pattern to automatically act on either one device or many.
But there’s also a school of thought that sees device-naming as not only unnecessary but even inadvisable. The device name is used by other systems—including Wi-Fi networks and Bluetooth—that may be vulnerable to snooping, so divulging almost any information about a specific device could in theory open that device to exploitation.
If you’re on the pro-names side of that debate, we have good news: Kandji has just released a new Library Item that allows you to automatically name iOS and iPadOS devices, as well as Mac computers. (We’ve previously supported doing so for Mac only.) You can find more details about that below. But first, we wanted to run through some of the device-naming strategies that real-world Apple admins use now.
Top Choice: Serial Numbers
We recently asked Mac admins on LinkedIn and the Mac Admins Slack channel how they name the devices they manage; we also posed the question to Kandji staff. The top response by far—from about a quarter of those we spoke to—was simple: They use the serial number as the device name.
Ease of use was one reason: There are no special tricks to acquiring a device’s serial number and assigning that as the device's name. Privacy was another: The serial number doesn’t divulge any information about the user that might be used by bad actors who intercept the name.
More importantly, many admins use the serial number because it (or a hostname based on it) can be used by multiple tools in the tech stack. As Caine Hörr on LinkedIn put it:
[The serial number] allows for a standardized, unified, and automated naming convention that crosses over from MDM to security tools, backup solutions, and directory services.
That’s not to say there aren’t serial-number dissenters. Their primary critique: even that number can open security risks. In theory, a bad actor could use it to deduce details about devices that might assist in an attack.
More practically, Apple’s serial numbers aren’t compatible with those used by other platforms, which could pose a problem in hybrid environments. One way admins get around that: Form the device name from the serial number (or part of it, such as its last X digits) plus some other identifier (such as the platform, country, or asset tag).
Usernames and Asset Tags
The most controversial choice for a device name: Anything based on username.
That variable still has many advocates among the admins we spoke to, particularly in conjunction with others (such as device model or serial number). The main reason: It’s a simple way to connect a device to a specific user. That can make servicing that device easier; absent other details, at least you know who to contact.
But the naysayers outnumber those advocates. The biggest problem is security: Username might have been fine when all those devices were on fixed networks behind firewalls. But in today’s open environment, it’s too easy for such details to leak. And if they do, the snooper could be halfway to authenticating into your systems (unless, of course, you’ve implemented the added protection of multifactor authentication.)
Asset tag also got a few votes. That has the advantage of connecting device and asset management. Also, physical tags sometimes fall off. If its number is embedded in the device name, you won’t lose it.
Complex Device Names
We heard from several admins who’ve developed truly impressive formulas that pack multiple device details into their names. Those details might include those above along with other variables, such as:
- Building number,
- Room number;
- Country code;
- Platform (Mac, Windows, and so on);
- Apple device type (MacBook, iMac, and so on);
- Apple hardware type (Intel or Apple silicon);
- Keyboard layout (for organizations with an international footprint);
- MAC address;
- Vendor (for non-Apple products).
Such complex solutions are particularly popular in education settings, where you might be managing labs full of dozens of devices. In that case, it helps to know not only which machine generated a ticket, but also where it’s located physically.
Those other details can also help with automations. For example, if you were enrolling a new Mac, and you knew from its automatically generated name that it was assigned to someone in the design department, you could configure your software-management solution to automatically install a copy of Final Cut. (For a more modern approach to this problem, see Kandji Blueprints.)
These details can also be useful to other components of the tech stack: Network and security admins might have their own needs that only a complex name can satisfy. For example, compliance teams might need to hold devices in different regions to different standards; a device name that includes that geographical piece can help.
Are Device Names Necessary?
We heard from several folks who said there’s no point in giving a device any formulaic name at all. They’d prefer to stick with the Apple default—”[first name of user]’s [device type]”—or whatever the user chooses. The main reason: Today’s management solutions have other ways to track device details, making it less necessary to embed them in a name. Besides, if users have admin accounts, they can rename their devices anyway.
The argument against the laissez-faire approach to device naming is that users could, if left on their own, choose even worse device names—”[my last name]+[last four of my social security number],” say. A consistent naming policy can forestall that risk.
More realistically, adopting a consistent naming pattern across the organization can make life easier for other teams. Whoever’s managing your network services, for example, might really appreciate having a simple way to identify the devices delivering and receiving network traffic; ditto with security, software licensing, and so on.
In some ways, the urge to name things is fundamentally human. It’s a way of understanding and controlling your environment. If it makes you feel better to apply consistent names to the devices you manage, go for it. It’s easy enough to do and it can help others.
Kandji’s Device Name Library Item
Which leads us to the impetus behind this post: Kandji’s new Device Name Library Item.
In the past, we had a parameter that let you set the device name on a Mac. We’ve now migrated that functionality to a Library Item and expanded its scope to iOS and iPadOS devices.
Using the new Library Item is the same as any other in Kandji: You select Library Item, configure the device-naming formula you want it to apply, and then add it to the Blueprints containing the devices you want to name. In configuring a naming formula, you can choose from:
- Asset tag
- Assigned user
- Blueprint name
- Company name
- Primary local user name
- Serial number
- Custom text
As you add variables, a preview shows you what the name will look like.
The Library Item also controls the hostname, which by default is the device name with spaces replaced with hyphens. (Other systems that rely on hostnames—such as security appliances on the network—don’t like spaces.)
Finally, the new Library Item also lets you decide whether users can modify their devices’ names. If you’re going to the trouble of naming them yourself, chances are you won’t want them to.
For more details on the new Device Names Library Item, check out our support article.
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.