A couple of years ago, I was at Identiverse in Washington D.C., delivering an in-person session about Identity and Access Management of Things. (Yes, in-person conferences feel like unreal events right now but it’s not what I want to talk about.)
At the time, I stressed the need to consider how relationships between things and with other identities were crucial to design and build a secure architecture for an IoT project. I also emphasized the great help provided by considering the full lifecycle of things as a means to think of many use-cases too often ignored. Relationships and lifecycle are powerful and well-known tools to identity professionals. But they rely on something which was obvious to my audience then: things need identities. Let me tell you why.
The need for identifiers of things.
Whatever the business use-cases, identifiers are almost always required: which electric pole needs maintenance? Which of the free-floating electric scooters has notified that its battery capacity is dying? Which of those thousand containers on the seaport has suffered violent manoeuvre and needs its content to be inspected? Which connected lock was broken?
The business teams, when they engage in IoT initiatives to gather, analyse data and act upon it, when they enhance physical objects with connectivity and provide new services to their customers, already define and extensively use identifiers to be able to reach their goals.
And I don’t think I’ll teach you anything if I tell you that business teams generally have the lead over IT people on such projects, leading to some caveats. One of those, perhaps the main one, is those projects manipulate business data (as they should) and such data is generally seen by IT people as exclusively business data (which it is not).
The need for identity of things
When engaging in an IoT project and specifically in its design phase (be it as an object vendor or as a company buying objets to connect to its Information System), IT people should probably take a step back and see those objects for what they truly are: entities that interact with the IS. And as such, things should definitely be seen as identities.
It sometimes feels like we’re back in 2004, before the digital transformation kicked-in in every company, when customers were merely treated as business data and not fully fledged identities accessing the IS, when any customer-facing website was rolling its own authentication system and where, if lucky, you’d end up with MD5-hashed passwords in a database. Remember? Do you want to relive that same story once again with thousands of connected things rolling their own home-baked authentication system? Yeah, me neither.
If an electric scooter reports its battery capacity is dying, that object effectively accesses the IS to write some value. Like an employee might access a monitoring application to update some records within a database or a customer will carry out a transaction on the e-shop actually launching an operation in some ERP.
Connected things should be first-class identities when communicating with the IS like any other workforce end-user, business partner or customer. This means having the means to identify and authenticate those things reliably, in a system designed exactly for this and not a side to the main course of the IoT initiative. This means relying on identity standards and well-known patterns for API calls (I’m hinting at OAuth2 here), notifications, update mechanisms, etc. Finally, this means using this identity and logging it through the hops of the communications and data transfers that happen and be able to use it further along in many situations.
And please bear in mind that this applies to both vendors and customer companies. Whether you design the IoT ecosystem and sell a product or a service or whether you evaluate several providers and the architecture they propose.
The need for IAM of Things
And this is just a part of the journey, once we have defined those identities and provided them with credentials to authenticate like any other users, we can, and should definitely, think about the next steps:
– Identity lifecycle management of things to be able to activate objects only when they should (not too soon in the factory but rather when they are deployed and initialized) and deactivate them in a timely manner (when it’s decommissioned or refurbished)
– Access control of things to make sure things only interact with authorized applications at the right time (things go through a series of states during their lifecycle and it should be taken into account) and with the right people (eg. authorized monitoring workforce or associated workforce or customer end-users)
– Identity analytics for things to monitor things behaviours and detect deviant or rogue ones, to provide insight back to business teams so they can analyse and optimize their processes
So basically things need identities and beyond that IAM of Things. And I feel compelled to say it out loud because I still regularly see IoT being deployed without a basic understanding of how things interacting with the IS are just like any other user interacting with the IS and why well-known identity patterns and standards should therefore be baked in the very design of well-architected IoT ecosystems to ensure stability, scalability and security.