OpenTelemetry’s 2026 roadmap points to easier observability governance

At a glance

What this is: This is a recap of OpenTelemetry updates and conference talks, with the key finding that the project is moving toward more usable, structured, and governable telemetry pipelines.

Why it matters: It matters because observability teams need to decide whether their data, collection, and control models can support richer telemetry without increasing cost, noise, or privacy exposure.

By the numbers:

• Real-world traces are massive, with around 200 attributes on median spans and 40,000-plus on p99 spans.
• Typical traces range from 50 to 500 KB, while some outliers reach 20 MB or more.
• 95%, verting time series into tiny ASCII line charts reduced token count by about 95%, from 122,000 to 372.

👉 Read Bindplane’s recap of OpenTelemetry updates and KubeCon observability sessions

Context

OpenTelemetry is becoming a governance problem as much as a technical standard. When telemetry grows into high-cardinality traces, structured logs, profiling signals, and eBPF-derived data, the question shifts from collection capability to control over what gets collected, normalized, retained, and sent onward. That matters to observability teams, but it also intersects with identity and access because the same pipelines often carry privileged system context, service credentials, and sensitive application data.

Bindplane’s recap of KubeCon + CloudNativeCon North America 2025 shows a project maturing toward more consistent configuration and richer signal types. The interesting part for security and platform teams is not the conference momentum itself, but the direction of travel: less fragmentation, more structure, and more pressure to govern telemetry as production data rather than engineering exhaust.

Key questions

Q: How should teams govern OpenTelemetry configuration across many services?

A: Treat OpenTelemetry configuration as a policy-controlled production asset. Use central change management, versioned rollout, audit logging, and role separation so a single configuration update cannot silently alter telemetry across many workloads. Governance should cover SDKs, collectors, retention settings, and any export destination that can widen access to sensitive runtime data.

Q: Why can richer telemetry create security risk instead of just better visibility?

A: Richer telemetry increases the chance that secrets, identifiers, or privileged context are captured and propagated into multiple systems. The more structured the data, the easier it is to correlate, but also the easier it is to over-collect. Security teams need filtering, redaction, and retention discipline before the data reaches downstream tools.

Q: What do security teams get wrong about observability in delivery pipelines?

A: They often stop at infrastructure telemetry and miss identity context. Logs, metrics, and traces are useful, but they do not answer whether the action was initiated by an approved service identity, whether the credential was expected, or whether access matched policy. Identity-aware observability is the missing layer.

Q: How do identity and access controls apply to telemetry systems?

A: Telemetry systems have their own privileged users, service accounts, and pipeline permissions. Teams should assign explicit roles for collector administration, data access, and export controls, then review those rights periodically. This reduces the chance that a debug workflow becomes an open channel to sensitive production data.

Technical breakdown

Declarative configuration in OpenTelemetry

Declarative configuration means the desired telemetry state is described centrally and then applied consistently across SDKs and instrumentation layers. In practice, that reduces per-language drift and makes onboarding easier because teams are not hand-tuning each implementation. The governance value is that policy can move closer to configuration, rather than being recreated in every service. For identity-aware environments, that matters because telemetry pipelines often touch service accounts, collector permissions, and downstream access to logs and traces. Consistency is useful only if the underlying permissions and data handling remain equally consistent.

Practical implication: tie collector and SDK configuration changes to the same approval and access controls used for other production policy changes.

Why structured logging and complex types matter

Structured logging keeps logs machine-readable without flattening nested data into strings, which preserves context for detection, debugging, and correlation. Complex types allow richer attributes such as arrays, objects, and nested values to survive export without losing meaning. That improves fidelity, but it also raises governance questions because richer logs can accidentally carry secrets, identifiers, or high-value operational context. The technical gain is better analysis; the control challenge is preventing over-collection and ensuring filters, redaction, and retention policies apply before data spreads across tools.

Practical implication: apply schema and redaction controls before export so richer telemetry does not become richer exposure.

eBPF instrumentation and profiling as production signals

eBPF lets instrumentation run closer to the kernel and infrastructure layer, which can reduce code changes while improving coverage across workloads. When paired with OpenTelemetry, that creates a more scalable way to observe performance, system behavior, and runtime activity. Profiling becomes especially interesting when it is transformed into metrics, because it shifts from ad hoc investigation to an alertable operational signal. Security teams should notice the access dimension too: deeper runtime visibility can reveal misbehaving processes, but it also requires careful control of who can enable, read, and export that data.

Practical implication: restrict who can activate profiling and who can read exported runtime data, especially in multi-team platforms.

NHI Mgmt Group analysis

Telemetry governance is becoming part of identity governance. OpenTelemetry is no longer just an engineering standard for metrics and traces. Once telemetry pipelines carry richer runtime data, teams must govern who can configure, read, and export that data with the same seriousness they apply to privileged access elsewhere. That makes the control plane, not just the data plane, the security boundary.

Declarative configuration creates policy opportunity, but also policy concentration. A unified configuration model reduces fragmentation, yet it also concentrates risk if changes are not tightly controlled. In observability stacks, a single mis-scoped policy can affect many services at once, which is why configuration governance needs auditability, segregation of duties, and change review. Practitioners should treat observability policy as production access governance, not tooling convenience.

Structured telemetry increases the value of redaction and minimisation. Rich logs and traces are useful only if sensitive fields are filtered before they propagate into multiple systems. This is where identity and data governance intersect: service context, secrets, and user identifiers can all leak through apparently harmless observability fields. The named concept here is telemetry exposure sprawl: the way observability data multiplies risk when one signal is copied into many downstream consumers. Teams should reduce the number of places sensitive telemetry can reach.

OpenTelemetry’s maturity reflects a broader shift from collection to control. The ecosystem is moving toward usable defaults, but the operational burden shifts to policy enforcement, safe instrumentation, and lifecycle management of telemetry access. That aligns with NIST CSF and NIST SP 800-53 thinking around access control, audit, and configuration management. Practitioners should assume that better observability will expose governance weaknesses faster, not hide them.

The AI observability thread is as much about restraint as capability. Talks on AI trace analysis and summarisation made a larger point: more data is not automatically more useful, especially when model processing introduces cost, risk, and false confidence. For teams exploring AI-assisted observability, the security question is whether telemetry can be compressed, governed, and scoped without handing broad runtime data to systems that should not see it. Practitioners should keep AI use cases bounded by data minimisation and explicit access controls.

What this signals

Telemetry maturity is moving the bottleneck from collection to control. As observability stacks become richer and more automated, teams will need clearer role boundaries around configuration, data access, and export approvals, especially where pipeline administration overlaps with privileged identity management.

Telemetry exposure sprawl: observability data rarely stays in one place once it is structured and exported, so minimisation and redaction must happen before fan-out. That is the same governance lesson identity teams learned with secrets and service accounts, and it now applies to logs, traces, and profiling data.

For identity and security programmes, the practical shift is to inventory telemetry administrators and data consumers as privileged identities. Where those identities are not governed, the observability stack becomes another route for sensitive operational data to accumulate and spread.

For practitioners

• Govern collector configuration as a production control Place OpenTelemetry SDK, collector, and pipeline configuration under change control, with approvals, rollback, and audit trails equal to other production policy updates.
• Minimise telemetry before export Apply filtering, schema enforcement, and redaction at the earliest practical stage so sensitive fields do not fan out across logs, traces, and downstream analytics.
• Separate runtime visibility from broad access Limit who can enable profiling, inspect high-cardinality traces, or export diagnostic payloads, especially where service context or privileged data may be present.
• Define telemetry access as an identity problem Map collector permissions, pipeline administration, and downstream analytics access to named roles and review them like other privileged identities.

Key takeaways

• OpenTelemetry is maturing into a governance layer as much as a technical standard, because richer telemetry changes who can see and control sensitive runtime data.
• The main risk is not observability volume alone, but telemetry exposure sprawl when structured logs, traces, and profiling signals propagate into too many systems.
• Practitioners should govern telemetry configuration and access like privileged identity controls, with filtering, redaction, and change control applied before export.

Key terms

• Declarative configuration: Declarative configuration describes the state a system should have, rather than the steps needed to build it. In practice, this makes reviews easier, supports repeatable deployments, and gives security and identity teams a stable reference point for drift detection and rollback.
• Unified Logging: Unified logging is the practice of collecting access and security events from multiple systems into one consistent audit trail. For AWS and NHI governance, it connects identity events to resource activity so teams can investigate misuse, prove compliance, and detect anomalous privilege changes more reliably.
• Telemetry Exposure Sprawl: The tendency for observability data to multiply across tools, teams, and storage locations once it is structured and exported. This increases the blast radius of any sensitive value embedded in telemetry, making access governance, filtering, and retention controls essential rather than optional.

What's in the full article

Bindplane's full article covers the conference-level product and community detail this post intentionally leaves for the source:

• Community call footage and floor interviews from KubeCon that show how practitioners are discussing OpenTelemetry adoption in practice
• Session-by-session talk notes on AI trace analysis, profiling, and structured logging from the event agenda
• Bindplane's own recap of Fleets and Blueprints with OpAMP, including the operational workflow behind large collector management
• Conference atmosphere, booth interactions, and maintainer conversations that are useful for context but not for implementation planning

👉 The full Bindplane post includes the conference talks, community highlights, and OpenTelemetry roadmap context.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners build the control discipline needed for modern identity and access programmes.