The Hidden Identity Risks Organisations Carry Into IT Modernisation

When a business moves its systems to the cloud, there's usually a good reason for doing it. Perhaps its existing infrastructure is becoming too expensive to maintain, or older applications are struggling to keep up with what employees need. There may also be security concerns that newer technology could help address.

Whatever the reason, the expectation is generally the same. The new environment should be better than the one it's replacing. But moving an application doesn't necessarily mean changing how people access it. An employee might still have permissions from a job they left years ago, while an automated process could be running under an account nobody has reviewed in ages. 

Those arrangements don't become more secure simply because the technology around them has changed. And when organisations are focused on getting everything migrated without disrupting the business, it's surprisingly easy for existing identity security risks to come along for the ride.

Why Identity Risks Survive IT Modernisation

Think about what happens when an organisation replaces an application that hundreds of employees use every day. It needs to transfer the data, configure the replacement and make sure everyone can still do their jobs. Nobody wants to spend Monday morning dealing with hundreds of employees who suddenly can't access their systems.

So there's a practical reason to preserve existing permissions wherever possible. The trouble is that those permissions may have been granted under very different circumstances, sometimes years before the migration was even considered. It's also rarely a case of switching off one environment and turning on another. 

According to Microsoft's guidance on moving identity and access management to the cloud, organisations can modernise users, applications and devices at different stages. That means some systems may still depend on the original Active Directory environment while others have already moved to Microsoft Entra ID.

This leaves IT teams managing a mixture of old and new access arrangements, often with different people responsible for different parts of the process. Unless someone takes the time to examine those arrangements, the migration can preserve weaknesses that have been building up for years.

Which Identity Security Risks Can Be Carried Into a New Environment?

Not every migration copies existing accounts and permissions exactly as they were. Some access arrangements need to be recreated, while others can be transferred or managed through connected systems. The risk depends on how the migration is handled and whether anyone checks what's being kept.

There are three areas where that assessment becomes particularly important.

Excessive and outdated access

Imagine an employee who started in finance, spent a few years in operations and now manages a completely different department. They've needed access to various applications along the way, but some of those permissions were never removed when their responsibilities changed.

Over time, they end up with access to information and systems they no longer need. This is known as privilege creep, and it's one of the reasons organisations need to review access regularly. 

Microsoft's identity governance operations guidance specifically identifies employees accumulating permissions as they move between roles and recommends that resource owners regularly check whether that access is still justified.

A migration gives organisations a chance to address this. But if the employee's existing permissions are simply recreated in the new system, nothing has really changed. They've still got access they shouldn't need, only now it's in a newer environment.

Overlooked service and privileged accounts

It's easy to think about identity security in terms of employees logging into applications, but plenty of accounts don't belong to people at all. Applications and automated processes often need their own accounts to exchange information or perform tasks without someone manually signing in. 

These are commonly called service accounts, and they can be difficult to keep track of, particularly when the systems they support have been running for years. Some also have extensive permissions because they need to perform administrative tasks or communicate with several other systems. 

If nobody knows who owns an account or what it does, deciding whether to migrate it becomes considerably harder. The same applies to privileged accounts used by administrators. Their access may be necessary, but it still needs to be justified. 

Organisations should know what each account can do, who is responsible for it and whether those permissions are appropriate for the new environment. Otherwise, an account that was poorly managed before the migration could remain poorly managed afterwards.

Legacy authentication dependencies

Then there's the problem of applications that still rely on older systems to verify someone's identity. For example, an organisation might move an application to newer infrastructure but discover that it still needs Active Directory to authenticate users. The application has moved, but part of the technology responsible for controlling access hasn't.

Microsoft's cloud-first identity guidance for IT architects recommends identifying these dependencies before migration. It specifically addresses applications using Kerberos, NTLM and Lightweight Directory Access Protocol (LDAP), which are technologies older applications may use to authenticate users or communicate with directories.

Some applications can be reconfigured to use newer authentication methods. Others need additional integration work or must continue relying on older infrastructure until a suitable alternative is available.

That's not necessarily a reason to delay the entire modernisation project. But organisations need to understand which dependencies will remain and what security controls they can apply to them.

Why the Migration Process Can Introduce Additional Risks

Even when an organisation has identified the problems it wants to address, the migration itself can make identity management more complicated. Large businesses rarely have the luxury of moving every application, account and device at once. Instead, they often spend months or longer operating across old and new systems. 

This creates a hybrid identity environment, where different parts of the business may depend on different systems to manage access. Consider a security team reviewing employee permissions through a cloud-based platform. They identify someone who no longer needs access to a particular application and approve its removal. 

Simple enough, except the group controlling that access might still be managed through on-premises Active Directory. Microsoft's guidance for planning access reviews explains that reviews can't directly change membership in certain groups synchronised from on-premises Active Directory. 

In those cases, administrators may need to apply the changes in the original directory, although other management arrangements are possible. So a review can identify a problem without automatically fixing it. If the teams involved don't understand which system controls the permission, the employee could retain access even after the review has been completed.

It's a useful reminder that identity governance depends on more than having the right tools. Someone also needs to know who's responsible for making changes and how to confirm they've actually taken effect.

How to Address Identity Risks Before, During and After Migration

The answer isn't to remove every old account or replace every application that still depends on legacy infrastructure. Some of those systems may be essential to the business, and changing them without understanding their dependencies could create problems of its own.

What organisations can do is make identity security part of the migration process from the beginning, rather than waiting until everything has moved. A practical approach involves three stages:

• Before migration: Build an inventory of user accounts, service accounts, privileged identities and applications. Establish how access is currently granted, which systems depend on older authentication methods and who owns each account or application. Work with those owners to identify permissions that are no longer needed.
• During migration: Check how access is being transferred or recreated, especially for accounts with administrative privileges. Where old and new environments operate together, establish which system controls each identity and how permission changes will be handled. Test that people can access what they need without retaining access they shouldn't have.
• After migration: Verify the permissions people and applications actually have, rather than assuming everything is correct because the migration succeeded. Remove obsolete accounts and dependencies when it's safe to do so, and establish regular reviews so unnecessary access doesn't start accumulating again.

This also needs cooperation between the people managing the migration and those responsible for the systems being moved. IT teams understand the technical requirements, but application owners are often better placed to explain who needs access and why. Security teams can then assess whether those arrangements introduce unnecessary risk.

There's no point removing a permission if doing so breaks an essential business process. Equally, keeping every permission simply because nobody wants to risk changing it defeats much of the purpose of reviewing access in the first place. 

The aim is to make informed decisions about what belongs in the new environment, rather than treating existing arrangements as something that must automatically be preserved.

Final Thoughts: Modernising Infrastructure Means Reassessing Access

Modernisation is an opportunity to improve more than the technology an organisation uses. It's also a chance to examine the access arrangements that have developed around that technology, sometimes over many years and without anyone questioning whether they're still appropriate.

A successful migration should leave organisations with a clearer understanding of who and what can access their systems, which dependencies remain and who's responsible for managing them. Getting there means asking the right questions before the migration begins, particularly about the permissions and accounts that might otherwise go unnoticed.

These are the kinds of challenges EM360Tech explores with enterprise technology leaders, helping organisations understand the risks behind major technology decisions. Because building a more secure environment starts with understanding what you're bringing into it.