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 let a client 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

SiAuth is our identity management system. To be clear about what that does and does not mean: we did not write our own authentication from scratch. SiAuth is built on an established, open-source authentication platform — a hardened, widely deployed system — configured to our own identity and access policies. Rolling your own cryptography is how organisations create vulnerabilities; standing up a proven platform inside a tightly scoped environment is the opposite of that.

It handles authentication across all Meridian applications — inSight, NOC Brain, SiSmic, SiDekick, SiNapse and SiNario Studio — for both our internal team and our clients.

Functionally, 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, because the system authenticates against our applications, not against Microsoft’s infrastructure.

Onboarding a new client now takes minutes rather than months.

When security control and operational practicality point in the same direction

Building your own identity system forces you to think clearly about identity and access management. 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 developed for client environments. Pulling them into a coherent 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 the compliance process asks for.

This was not the reason we built SiAuth. But it is a useful illustration that security controls and operational practicality are not always in tension — and that the organisations which find compliance frameworks most burdensome are often the ones that treated security and operations as separate problems. The same decision, made once and made properly, can resolve both.

The question worth asking before implementing anything

Our strapline is matching technology to business needs. Microsoft SSO did not match ours. 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 in front of you.

AI-assisted development has changed the calculus. Building a custom authentication layer is no longer a project that needs a dedicated 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 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 operational realities, not abstract policy questions. 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.