What if you demanded a picture ID for everyone you meet, whether they’re complete strangers or long time friends since grade school? You’d certainly end up with a much diminished social network, and while it may be appropriate in some professional situations, colleagues would eventually avoid collaborating with you, the punctilious and annoying pedagogue.

So why do we require the same user authentication in the digital realm, regardless of context? Or as users, tolerate it?

On one hand, pocket sized mobile devices magnify the risk: users may try to access enterprise resources from their home office, an airport lounge, or while on holiday in Budapest. How can you be sure it’s your trusted employee with their finger on the screen and not a cyber mafioso who’s paid a gypsy pickpocket for Apple picking?

On the other hand, new devices bring new context, such as geolocation, which can be used as a factor in deciding whether to trust the user’s access attempt. The trick is balancing identity confidence with end user convenience. With IBM’s Identity and Access Management solutions, you can:

1. Identify the device. With device “fingerprinting”, transparent to the user after an initial consent based registration, devices can be positively identified. A revocation list denies accesses and alerts response staff for lost or stolen devices.
2. Identify the context. The IP address, application being requested for access, and details of the transaction are some of the factors that can be applied to context.
3. Decide the current level of risk using the context and qualifying information,  such as the reputation of the source IP address—is it on a known hostile network?—or whether the transaction is high value vs a typical money transfer under $1,000.
4. Choose an appropriate authentication mechanism. If the device is on a corporate network perhaps a simple username and password is all that’s required; however, if the access is from outside the country or the transaction is sensitive, perhaps stronger authentication, such as a one-time password, facial or voice recognition, or fingerprint—or a combination—is called for.
5. Authenticate the user and assign reasonable access controls. Of course the user has to provide the correct credentials, but also be limited to systems, transactions, and behaviors appropriate to the context and authentication provided. Just because the user asked for access to email doesn’t mean they should also have access to schematics for the time machine project.

Of course, like your relationships, the reach and roles of identities within an enterprise is complicated. To accommodate IT administrators and business associates, and integrate with multiple organizations, you’ll also need privileged identity management (PIM) as well as federated identity management and directory services (FIM and FDS). PIM gives you control over accounts with Administrator and root privileges, including full auditing and even session replays. FIM and FDS give you control over identity management between organizations, including cloud services.

In keeping with the tenet of “trust but verify”, identity management, no matter how sophisticated, must be complemented by security intelligence. IBM’s QRadar collects identity activity in addition to systems and application events, network activity, and context from configuration and vulnerability management systems, and then synthesizes all that information to detect unauthorized or suspicious behavior. We tend to trust our neighbors, but heard too often on the evening news is, “He’s such a quiet guy. We never suspected…”

With the amount of context available in today’s devices, as well as the data (“big data”) they generate, there’s no reason to burden the user population with inflexible security technology and practices, or be surprised by a rogue, trusted insider.