Why we need Multiple Identities

A recent news article reminded me of a recurring question that pops up with groups that I’ve worked with: can an individual have more than one identity?

The answer is yes, whether we like it or not. Not all products or solutions can work with that answer though.

I think every system should start with the assumption that an individual may hold more than one identity, and if it’s impossible to handle, then the limitations should be recognised and ideally compensated for.

Consider the following scenarios:

• An individual needs to change identity to protect themselves or their family from an abuser (as per the article linked above).
• An individual goes into a Witness Protection Program.
• An individual is working for an organisation in multiple roles at once in different contexts, and their contexts dictate different levels of privileges to see information (e.g. Contractor, Permanent Employee, and Customer).
• People are working in classified environments, and any knowledge of their existence to others in the organisation could be a breach of security, but they use an alias to access day-to-day systems.
• An individual is performing tasks on behalf of another person, such as with Power of Attorney privileges.
• An individual’s entire identity is stolen, requiring them to reset and change all identifying information.

Probably the most common scenario people encounter in the IT security world though is with sysadmins using a separate identity to access administrative functions. Ideally, sysadmins should hold at least two accounts. One for day-to-day work, and another for sysadmin access. If a sysadmin is logging into their work PC and checking email with their administrative account, and then logging into a Tier 0 machine (like a domain controller), then your organisation is at high risk of compromise. Keeping the two separate adds overhead for the management of two identities for a single user.

I believe the best approach is ultimately for systems to just allow multiple identities, and if you need proof to be established for each identity, then allow identity proofing to occur as many times as a user wishes across whatever identity they wish to use. For systems to link some sort of service to a single identity, that’s fine - build in transferral processes of these services to give the user the control.

For example, a user registers with a system to legally submit a Tax Return. One year they authenticate with a proven identity and submit the form successfully. Next year they forget their old authentication credentials, so they register again as a new identity to submit the new year’s form. As long as they can prove their identity correctly, this shouldn’t be an issue - a proven identity has submitted the form and satisfied the submission requirements for both years. Linkage of the two identities can then be made if needed, as there will probably be some unique identifier that remains constant between the two submitted forms (such as a Tax File Number).

If risks remain for a malicious actor to register a fake identity for another person and submit forms as them, then you obviously need to address issues with your identity proofing process, not the fact that identities could undergo proofing more than once.