How should organisations implement Zero Trust when cloud visibility and logging are still fragmented?

Build Zero Trust Around Better Telemetry, Not Perfect Telemetry

zero trust does not require complete visibility on day one, but it does require a deliberate path from fragmented logging to decision-grade telemetry. The practical objective is to make access, change, and response observable enough that defenders can validate identity signals, compare activity across cloud services, and narrow investigations to the systems that matter most.

That means prioritising the log sources that answer the highest-value questions first, especially identity events, privilege changes, configuration updates, API activity, and security-relevant control-plane actions. If those signals remain scattered, analysts cannot reliably test assumptions about trust, blast radius, or whether a request was legitimate.

When organisations are still early in the journey, NIST SP 800-207 Zero Trust Architecture is the clearest anchor for the operating model: continuous verification, least privilege, and policy decisions based on current context rather than implicit trust.

Which telemetry gaps break Zero Trust first?

The first gap is usually not the absence of logs, but the absence of a common view across them. Cloud providers, SaaS platforms, and identity systems often emit useful events, yet the events are stored in different places, use different timestamps or schemas, and are not retained long enough for real investigations. That leaves security teams unable to reconstruct a sequence such as login, role change, secret use, and data access.

In practice, the most damaging gaps are those that hide privileged actions and trust changes. If you cannot see who changed a security group, who granted a token, or whether a workload assumed a new role, Zero Trust becomes a slogan rather than an enforcement model. A useful reference point for workload-level trust signals is Guide to SPIFFE and SPIRE, because it shows how workload identity and attestation can reduce ambiguity in service-to-service access.

Visibility also needs to cover identity governance, not only runtime access. Centralising telemetry without understanding entitlements, ownership, and privileged paths still leaves blind spots around standing access and stale permissions. For teams building that bridge, IAM and IGA Basics is a useful way to connect authentication, authorization, and access reviews to the logging model.

The point is to make telemetry usable for a specific decision, not merely available in bulk. If the response team cannot answer whether a suspicious action came from a human admin, an automated workload, or a delegated integration, then the logging estate is still too fragmented for Zero Trust operations.

What does a phased implementation look like when logs are fragmented?

Start with a minimal telemetry backbone: consolidate the logs that prove identity, privilege, and change first, then expand into workload, network, and application signals. The first wave should support account activity, privileged role assignment, session events, configuration drift, and cloud control-plane changes. Those are the events most likely to determine whether a trust decision was justified.

Next, standardise retention and access. Retention should be long enough for investigation and post-incident reconstruction, while access should be broad enough for security operations to query without waiting on platform owners. If analysts must request ad hoc extracts every time, response will always lag behind the attack or misconfiguration window.

Then align detection and response workflows to the telemetry you actually have. That means mapping alert logic to specific evidence sources, defining which team owns each signal, and deciding where identity, cloud, and incident response tooling hand off to one another. For teams that want a broader blueprint for that identity-centric operating model, Zero Trust Identity Guide is a good companion reference.

Finally, make the rollout measurable. A fragmented environment becomes manageable when you can show that the time to correlate a change across environments is falling, that high-value events are retained consistently, and that security operations can validate suspicious activity without manually stitching together multiple console views.

Risk and Threat Considerations

Fragmented visibility creates an attacker advantage because it slows detection, weakens correlation, and makes trust decisions harder to verify. In a cloud environment, that can let privilege changes, token abuse, or configuration tampering blend into normal administrative noise until the damage has already spread.

Failure mechanism: Defenders cannot reliably reconstruct the sequence of events across identity, control plane, and workload telemetry, so malicious or unsafe activity persists longer and appears less connected than it really is.

Impact: The organisation loses confidence in its Zero Trust enforcement, increases dwell time, and risks missing lateral movement, excessive privilege use, or unauthorized change before it reaches production impact.

Practitioner Guidance

What to prioritise: Put identity, privilege, and configuration-change telemetry ahead of broad data collection. Those signals usually deliver the fastest improvement in investigative clarity because they answer the question Zero Trust cares about most: what changed, who changed it, and under what authority?

What to verify: Confirm that security operations can search and retain the same event types across cloud accounts, and that the evidence needed for an investigation survives long enough to support after-action review. If the answer depends on someone exporting logs by hand, the control is still too immature.

Practitioner takeaway: Zero Trust becomes operational only when visibility is good enough to challenge trust decisions in real time; until then, the right goal is not perfection, but reliable correlation of the events that most affect privilege and change.

Related resources from NHI Mgmt Group

• How should organisations implement zero trust in hybrid environments with both cloud and on-premises resources?
• How should organisations implement zero-trust architecture when they still rely on legacy and non-containerised systems?
• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?