When the standard creates the problem

Meridian includes inSight, our network intelligence and monitoring platform. We had been running our own internal access on Azure SSO without issues. But when we started onboarding clients — giving them visibility into their own connectivity and network health through the platform — we hit a wall.

To allow a client to log into an application via Azure SSO, they need to authorise that application inside their own Entra tenant. This is a reasonable security requirement. It is also, in practice, a significant friction point. Security reviews, change control processes, stakeholder sign-offs. We once waited three months for a single SSO federation to clear the queue at a client’s organisation.

That is three months of delay before a client can access something they are paying for and that we have already built.

Building what the requirement actually needs

SiAuth is our own identity management system, built on an open-source authentication platform. It handles authentication across all Meridian applications — inSight, NOC Brain, SiSmic, SiDekick, SiNapse, SiNario Studio — for both our internal team and our clients.

From a functional standpoint, it does what Azure SSO does: single sign-on, role-based access, user management. The difference is that it operates in a closed, scoped environment. We define what it can access. There is no risk of inadvertently granting a client’s login broader permissions inside a Microsoft tenant than intended. The system authenticates against our applications, not against Microsoft’s infrastructure.

Onboarding a new client now takes minutes rather than months.

When security controls and operational practicality point in the same direction

Building your own identity system requires you to think clearly about your identity and access management policies. What are the password requirements? How is recovery handled? What constitutes a legitimate access request? Who can grant permissions, and who reviews them?

We already had years of documented thinking on these questions — policies and standard operating procedures we had developed for client environments. Pulling them together into a coherent, internally consistent framework for SiAuth produced a documentation pack that directly addresses a significant portion of the Cyber Essentials identity and access management requirements. The discipline of building the thing generated the evidence that the compliance process asks for.

This is not the reason we built SiAuth. But it is a useful demonstration that security controls and operational practicality are not always in tension. Sometimes one produces the other.

The discipline of building a security control properly tends to generate its own compliance evidence. The organisations that find compliance frameworks burdensome are often the ones that treated security and operations as separate problems — when the same decision, made once, resolves both.

The question worth asking before implementing anything

Our strapline is matching technology to business needs. Microsoft SSO did not match our business needs. It matched a general pattern, and that general pattern created a specific problem for us.

The question we ask before implementing anything — for ourselves or for our clients — is whether the technology actually fits the requirement, or whether we are shoehorning a standard into a situation that needs something different. Sometimes the standard is exactly right. Sometimes it is overkill. Sometimes it solves a different problem than the one you have.

AI-assisted development has changed the calculus here. Building a custom authentication system is no longer a project that requires a development team and a six-month runway. We built SiAuth as part of a broader engineering effort, tested it, and deployed it to the full team in a matter of weeks. The option to build something specific is now genuinely available in situations where it previously would not have been.

Identity management is a foundational security control. Who can access what, under what conditions, and how that is reviewed — these are not abstract policy questions. They are operational realities. How you answer them matters more than which vendor’s name appears on the login screen.

If the way your business accesses its tools is creating friction rather than removing it, that is worth a conversation about whether the right controls are actually in place — or just the conventional ones.