{"id":13454,"date":"2026-09-22T10:00:00","date_gmt":"2026-09-22T10:00:00","guid":{"rendered":"https:\/\/meriaky.com\/?p=13454"},"modified":"2026-09-20T19:14:51","modified_gmt":"2026-09-20T19:14:51","slug":"access-management","status":"publish","type":"post","link":"https:\/\/meriaky.com\/en\/blog\/access-management\/","title":{"rendered":"Access management: the stranger who changed our automation in May"},"content":{"rendered":"\n

Access management means knowing who can get into which tool, and being able to remove that access the same day.<\/strong> Still, it is not a big-company topic. It is what keeps a stranger from changing your systems without you knowing.<\/p>\n\n\n\n

In fact, we lived it last week with a client. An automation we had set up in December had started sending messages on dates nobody had planned.<\/p>\n\n\n\n

Access management: the story of the unknown user ID<\/h2>\n\n\n\n

The client calls us because a seasonal automation no longer does what we set up. So we open the version history. Our last change is dated December 9, according to the history. Then, on May 6 and 7, someone else went in.<\/p>\n\n\n\n

Someone, yes, but who? The history shows a user ID, a string of characters, not a name. Next, we dig through emails, cross-check dates, search. Finally, the most likely explanation: a former team member, gone for months, whose account was never closed.<\/p>\n\n\n\n

However, the change itself was not malicious. She had simply added new send dates. In fact, the problem was that a person who no longer worked there still had her hands on the system, and nobody knew.<\/p>\n\n\n\n

Why access management goes wrong in a small business<\/h2>\n\n\n\n

Access management goes wrong because it happens at the entrance and never at the exit. You create accounts when someone arrives. Then you forget to close them when the person leaves.<\/p>\n\n\n\n

Yet in a small business, departures are rarely clean. An intern finishes her contract on a Friday. A contractor delivers his project and moves on. A partner leaves the venture. In that moment, the urgency is keeping the work going, not closing accounts.<\/p>\n\n\n\n

For example, the Canadian Centre for Cyber Security<\/a> says it in its baseline controls for small organizations: each user should have a unique individual account, and there should be a process to revoke accounts when they are no longer required, such as when employees leave. Simple on paper. Still, almost never done.<\/p>\n\n\n\n

The shared account, enemy number one<\/h2>\n\n\n\n

The shared account makes any access management impossible. Because when three people use the same login, the history tells you someone did it, never who.<\/p>\n\n\n\n

Of course, the reflex is understandable. Paying for one more seat costs money, and passing the password around is faster. But the day one person leaves, you cannot close her access without cutting off the other two. So you do nothing, and she keeps the door open.<\/p>\n\n\n\n

\"Hand<\/figure>\n\n\n\n

Then, when a change causes a problem, as it did with our client, you cannot even know who to ask. In other words, one account per person is what makes the history useful.<\/p>\n\n\n\n

Access management in four moves<\/h2>\n\n\n\n

Access management that holds up in a small business does not require an IT department. Instead, it requires a list and four moves.<\/p>\n\n\n\n