Every IT environment I have ever looked at has at least one thing that was supposed to be temporary.
A shared admin account created "just for this migration" two years ago. A flat group structure that was going to be reorganised "when things calm down." A manual onboarding process that has been "about to be automated" since 2023.
I am not pointing fingers. I have done all of these myself. The temporary thing works, something more urgent always comes up, and before you know it the temporary thing is load-bearing infrastructure that everyone is afraid to touch.
But I want to talk about why this pattern is particularly risky in identity management. In most areas of IT, technical debt slows you down. In identity management, technical debt is a security gap.
The greatest hits
Let me list the temporary things I see most often when talking to Nordic companies. See how many sound familiar.
The shared admin account. Created because two people needed admin access and "it was faster this way." Still active. Password last changed: unclear. MFA: not configured, because it is a shared account and nobody wants to deal with the logistics. Audit trail: useless, because you cannot tell which human did what.
The "just give them the same access as" onboarding. New person starts, someone says "give them the same groups as Johan." Johan has been at the company four years and has accumulated access from three different roles. The new hire now has access to things they will never need. This repeats with every new joiner. Access creep becomes the default.
The offboarding that is mostly done. Account disabled, sure. But the SharePoint permissions? The shared mailboxes? The external SaaS accounts? Those get cleaned up "later." Later does not come.
The group structure nobody understands. 60 security groups in Active Directory, another 25 cloud-only groups in Entra ID, and half of them have names like "Project X Team" or "Test - do not delete." Some have members. Some are empty. Some sync from AD to the cloud, some do not, and nobody remembers why. Nobody knows which ones are actually referenced in conditional access policies or application assignments. Deleting any of them feels risky, so they all stay.
The PowerShell script one person wrote. It runs nightly. It does something important. The person who wrote it is on semester. Nobody else knows where the script lives or what happens when it fails. (It does not notify anyone when it fails.)
Why "later" never arrives
There is a specific psychology to this. The temporary thing works. It is not causing visible problems right now. And the effort to fix it properly feels disproportionate to the immediate benefit.
Fixing the shared admin account means setting up Privileged Identity Management. That is a project. Reorganising the group structure means understanding what every group does across both AD and Entra ID, which means talking to people, which takes time. Automating onboarding properly means connecting the HR system to your identity platform, defining rules, testing them, getting sign-off.
Each of these is real work. And each competes for time against things that are actively broken. The broken printer wins over the insecure-but-functional shared admin account every time.
So "later" is not laziness. It is rational prioritisation in the moment. The trouble is that the moment never changes. There is always a broken printer. There is always something more urgent.
The compound effect
One temporary workaround is manageable. Five of them start interacting in unexpected ways. Ten of them, accumulated over a few years, and your identity environment is held together by things nobody fully understands.
This is when risk becomes real. Not because any single shortcut is catastrophic on its own, but because the accumulated weight of deferred decisions creates an environment that is fragile, opaque, and hard to audit.
An auditor asking "who has admin access and why?" should have a simple answer. When the answer involves a shared account, three overlapping groups, and a PowerShell script, it is not simple anymore.
A security incident requiring "revoke all access for this person immediately" should take minutes. When their access is spread across manually assigned groups, direct application assignments, and shared accounts, it takes hours. If you can even find everything.
The fix is smaller than you think
I am not going to tell you to fix everything at once. That is how "fix it properly" projects get abandoned halfway through, usually around the time something urgent comes up (which it always does).
Pick one thing. The most risky temporary thing in your environment. The shared admin account is usually a good starting point because the risk is clear and the fix is contained.
Then set a 90-day calendar reminder for the next one.
The goal is not to eliminate all technical debt overnight. The goal is to stop accepting it as permanent. "We will do it properly later" is fine, as long as "later" has a date.
Set a 90-day reminder right now. Put the name of the thing you have been meaning to fix. See if you actually fix it.
I think you will. Because now it is in your calendar, looking at you.