Single Pane of Glass: What It Actually Means Technically (And Why Most Vendors Miss It)

TL;DR: "Single pane of glass" is sold as a UI feature, but it is really a contract between four subsystems (a shared asset model, an event bus, a search index, and a federated identity plane) that must agree on what a thing is, who owns it, what happened to it, and who is allowed to know. When those four disagree, you end up with a portal rather than a platform; when they line up, the dashboard is almost an afterthought.

Every SOC vendor claims a single pane of glass. The phrase has been worn smooth. In practice it usually means a portal with iframes: one tab for the EDR, one for the vulnerability scanner, one for the asset inventory, each rendering its own native UI inside a wrapper that shares only a logo. The user sees one URL. The data has not been unified at all.

This post is about what it actually takes, at the architecture level, to build the other kind of single pane: the one where an alert raised by the endpoint agent, an asset record imported from the CMDB, a vulnerability surfaced by the scanner, and an incident ticket opened by the SOC analyst are all references to the same underlying entity, queryable with the same syntax, governed by the same role.

It is the substance behind Krasper Suite, and the part that older vendors tend to skip, because retrofitting it onto a federation of acquired products is harder than selling around it.

Contents

1. The marketing version vs. the engineering version
2. The shared asset model: why the canonical ID is the entire game
3. The event bus: choreography over orchestration
4. The search surface: when full-text actually matters
5. Identity federation with OIDC: one user, many subsystems
6. Hexagonal architecture: what holds it together
7. Operating a dozen-plus services without losing the thread
8. The checklist: how to evaluate any vendor's claim

1. The marketing version vs. the engineering version

The marketing version of a single pane of glass is:

"All your security tools in one place."

Which is a claim you could equally make about any browser with a bookmarks folder.

The engineering version is harder to fit on a slide:

Given any entity in the platform (an asset, a finding, an incident, a user, a policy), every subsystem that observes it must agree on its identity, must publish state changes to a shared timeline, must expose its data through a common query surface, and must defer authorization to a shared identity plane.

That sentence describes four contracts. Most platforms get one, usually the dashboard layer, and call it a day. The rest is glued together with nightly batch jobs and a hope that nobody notices the join keys do not quite match.

Hold those contracts and the dashboard is just a thin rendering layer over consistent data. Let them slip and the same dashboard becomes camouflage over four inconsistent stores, where every cross-cutting question, "show me every host that has a critical CVE, an active EDR alert, and an unpatched OS, owned by the finance team", needs a human to run four searches and stitch the results together by hand.

2. The shared asset model: why the canonical ID is the entire game

The hardest problem in this kind of platform is not the alert volume or the dashboarding. It is entity resolution. The endpoint agent calls a machine LAPTOP-7HD23-NEW. The vulnerability scanner calls the same machine by its IP, which changes weekly. The CMDB has it as asset-id-44219. The ticketing system references it by serial number. Cloud asset discovery sees it as an EC2 instance ID.

If those identifiers do not converge, every "cross-tool" query is guesswork.

The fix is a canonical asset model owned by the platform, not by any individual integration. Each integration is responsible for resolving its native identifier into the canonical one at ingestion time, not at query time:

Once every observation carries the same canonical_asset_id, every question becomes a single query against a single index, regardless of which subsystem originally produced the data. The asset becomes the join key for the entire platform.

The unglamorous truth is that most of the engineering work on a unified SOC platform is spent on this resolver: the rules, the fallback chains, the conflict handling when two integrations disagree, the merge logic when a previously unknown asset is later identified. None of that can be shortcut, and vendors that skip it end up with parallel asset universes, leaving the customer's analyst to do the reconciliation in their head.

3. The event bus: choreography over orchestration

The second contract is the event bus. Every state change in every subsystem (a new alert, a closed finding, an asset coming online, a policy updated, a comment added to an incident) gets published as an event onto a shared bus. Other subsystems subscribe to the events they care about.

The architectural choice we made early was choreography over orchestration. There is no central workflow engine telling the incident system "now wait for the vuln scanner to finish". Each service reacts to events at its own pace, in its own bounded context, and publishes its own events when its state changes. The bus is the only coupling.

The payoff:

• A new subsystem can be added without modifying any existing one. It just subscribes to the events it cares about and publishes its own.
• Replay is trivial. Any consumer can rewind to a point in time and rebuild its derived state from the event stream, useful for backfills, bug fixes, and disaster recovery.
• The audit trail is a side effect of the architecture, not a feature bolted on later. Every state change is already serialized in chronological order.

The cost is that consistency becomes eventual rather than transactional. A new alert may arrive at the dashboard a few hundred milliseconds before the asset enrichment catches up. The platform has to display gracefully in that window. The engineering discipline this forces is healthy: it pushes you to design UIs that show what is known so far rather than blocking on everything that could possibly be known.

A concrete event shape, redacted of internal naming, looks like this:

Notice three things: the canonical asset ID is a first-class field, the tenant is explicit (no implicit context), and the payload is namespaced to the event type. Those three habits eliminate roughly 80 percent of the integration pain that comes later.

4. The search surface: when full-text actually matters

Once events and assets are unified, the next question is how analysts actually query them. Two failure modes are common:

1. The platform exposes a separate search box per subsystem. Analysts guess which box to type into. Wrong guess = empty result, even though the answer existed two boxes over.
2. The platform exposes one search box that only does exact-match on canonical fields. Analysts try error 504 nginx finance-team and get nothing, even though the words appear across three different alert payloads.

A unified SOC needs full-text search that spans every entity type (assets, alerts, findings, incidents, comments, tickets) and respects structured filters on the same query.

This is where a dedicated search index earns its keep. We index every entity at the moment its event hits the bus, with the canonical asset ID as a facet, the tenant as a hard filter, and the free-text payload fields as searchable content. The query language supports both:

That query reaches into incidents, alerts, and findings simultaneously, respects RBAC on the asset owner field, and returns ranked results across entity types. The analyst does not have to know which subsystem owns which field. That is what "single pane" means in practice.

The lesson here is to treat search as a platform capability, not as a per-service feature. A unified index is a force multiplier; per-service search bars are a tax on every investigation.

5. Identity federation with OIDC: one user, many subsystems

The fourth contract is identity. If the analyst signs into the dashboard but each subsystem maintains its own user table, you have a single login at best, not a single identity.

OIDC, with a dedicated identity broker in front of every subsystem, is the unfussy way to solve this:

A single role assignment in the identity broker propagates to every subsystem on the next token refresh. There is no per-service user management. There is no out-of-band synchronization job that drifts. When an employee leaves and the IdP deactivates them, every subsystem loses access at the same moment because every subsystem requires the same token, and the token requires the same identity, and the identity no longer exists.

OIDC also gives us tenant isolation at the token layer: the tenant_id claim is part of the access token, every API request is scoped to that tenant by the gateway, and a service that ignores it cannot ship past review because integration tests fail.

None of this is novel; it is the standard pattern. What matters is using it consistently across every single subsystem, with no exceptions "because integration X was acquired and still has its own user model." The exceptions are where the single pane stops being single.

6. Hexagonal architecture: what holds it together

The architectural style that makes these four contracts maintainable over years rather than months is the one variously known as hexagonal architecture, ports-and-adapters, or clean architecture. The shape is always the same: a domain core that knows about entities and business rules, surrounded by ports (interfaces) that define how it talks to the outside, and adapters (implementations) that bind those ports to specific technologies.

Concretely, the asset domain does not know whether asset data lives in PostgreSQL, comes from a REST integration, arrives over the event bus, or is searched via an external index. It only knows that AssetRepository, AssetEventPublisher, and AssetSearchIndexer are ports it can call. The adapter layer wires those ports to the actual infrastructure.

The payoff shows up exactly when you need it most:

• Swapping the search backend is a one-adapter change, not a domain rewrite.
• Adding a new integration is an adapter on the other side, not a surgical edit through the entire stack.
• Testing the domain is trivial: every port has an in-memory fake. No mocked HTTP calls, no test containers required for unit tests.
• Onboarding new engineers reduces to "learn the domain language; the infrastructure is changeable detail."

The discipline is harder than it sounds. The temptation to reach directly into the database from a controller, "just this once for performance," is constant. Holding the line on the boundary is what prevents the platform from collapsing into a distributed monolith under its own weight.

7. Operating a dozen-plus services without losing the thread

A platform built this way decomposes naturally into a dozen-plus independently deployable services: each one a bounded context, each one with its own database, each one publishing to and subscribing from the shared event bus, each one exposing its API behind the shared identity gateway.

A few operational lessons stand out from running that many services in production.

Versioning the event schema is non-negotiable. Every event type carries a schema version field, consumers tolerate the version they were built for and ignore unknown future fields, and breaking changes ship as new event types rather than in-place rewrites. It sounds obvious, but the cost of getting it wrong even once is a multi-week migration across every consumer.

Observability has to be a platform capability rather than something each service reinvents: one structured log format across all services, one distributed trace ID propagated through the bus, one metrics namespace. Build this on day one or fight it on year three.

Idempotency keys belong on the bus. Every event carries a unique event_id and every consumer deduplicates on it, which collapses an entire class of "did the email send twice" bugs before they happen.

On storage, prefer schema evolution to data migration. Add new fields, soft-deprecate old ones, and never delete; an extra column costs almost nothing, whereas a coordinated stop-the-world migration across a dozen services is ruinous.

Finally, keep one golden integration-test environment with real services. Unit tests can pass against fakes, but integration tests have to run against real services in compose, because mocked integration tests keep passing exactly when production breaks.

8. The checklist: how to evaluate any vendor's claim

If you are evaluating any SOC platform that claims a single pane of glass, the questions worth asking, in order of how reliably they distinguish substance from marketing, are these.

First: what is your canonical asset identifier, and how is it derived from native identifiers across integrations? If the answer is vague, the platform does not have one.

Second: show me a query that spans more than one subsystem and returns ranked results in a single pass. If the demo opens two browser tabs, that is your answer.

Third: when I revoke a user in our IdP, how long until every subsystem in your platform denies their token? The honest answer is "on next token refresh, typically under five minutes." Anything longer than that means out-of-band user sync, which means drift, which means audit findings.

Fourth: describe how a new integration is added. If the answer involves modifying anything outside the integration's own bounded context, the architecture is coupled tighter than the marketing claims.

Fifth: show me the event schema for one of your core entities. If there is no event schema, there is no event bus, and the "single pane" is held together by polling and prayer.

A platform that answers these well has put in the engineering; one that deflects them has put in the marketing. That gap matters most when a real incident spans three subsystems and your analyst has six minutes to triage it.

Closing

A single pane of glass is an architecture commitment that happens to surface as a dashboard: underneath it sit a shared asset model, an event bus, a unified search surface, and a federated identity plane, wrapped in modular boundaries that let the platform evolve without rewrites.

Everyone sees the dashboard. Whether it is telling the truth comes down to those four contracts beneath it.

The next post in this series walks through one of those contracts in depth (the event bus) and what its schema, consumer contract, and replay tooling look like in practice.

Further reading

• Alistair Cockburn: Hexagonal Architecture (2005)
• Martin Fowler: Event-Driven Architecture and Choreography vs. Orchestration
• Sam Newman: Building Microservices, 2nd ed.
• NIST SP 800-207: Zero Trust Architecture