Runtime security is becoming a network architecture imperative for telecom operators, writes Nokia. To detect threats earlier without compromising performance, security must deliver continuous visibility, operate predictably under load, and align with stringent operational, validation and regulatory requirements.
Telecom networks operate continuously under load, with behavior that has to remain stable and secure at all times. In this environment, stealthy activity is difficult to detect. It blends into normal operations, moving alongside expected behavior.
Instead of alarm bells at entry, what surfaces usually is the downstream consequence: a service issue, compliance trigger, or escalation outside the security operations center, by which point response options are limited.
Detecting threats earlier means moving security into service-bearing network functions, where strict availability and performance limits apply. If runtime security cannot operate safely within those constraints, it starts adding risk instead of reducing it.
This turns runtime security into a network architecture decision, with a direct impact on service continuity, regulatory confidence, and operational cost.
In practice, runtime security only works within telecom environments if a few conditions hold.
1 | Behavior is seen in sequence
A process start, system call, configuration change, or protocol exchange can each look normal on its own. Only when they are connected over time does the pattern begin to stand out. Intermittent inspection breaks that sequence, capturing snapshots and missing how activity unfolds between them.
Runtime signals need to follow execution as it happens – tracking how processes evolve, how communication shifts, and how actions relate during live operation. This is what separates gradual divergence from normal change without disrupting service.
AI-driven detection depends on the same continuity. When observation fragments, context thins, and low-noise activity match what looks normal.
2 | Operation remains stable under load
Runtime security runs inside production systems, sharing compute and scheduling with latency-sensitive workloads while remaining bounded and predictable, even at peak demand.
These constraints shape how observation is applied. Adding logic into workload execution or packet handling creates coupling to network function lifecycles and expands operational pipelines (build, deploy, upgrade, validate), where each step adds change risk and governance cost.
Platform-level observation fits telecom operations more naturally. It follows host and kernel lifecycles already inherited by network functions, reducing lifecycle coupling and supporting controlled rollout across multivendor environments.
3 | Trust and lifecycle stay controlled
Running security inside the kernel extends what needs to be governed. Its lifecycle requires guardrails such as verified delivery, constrained privileges, and validation to preserve expected system behavior and execution semantics.
In many telecom environments, introducing new software components can trigger extensive qualification and testing requirements. Security technologies that require coexisting kernel versions, staged upgrades, or workload-specific integrations can increase overhead and slow validation cycles.
Runtime security fits when it moves with these cycles and follows established validation processes. Portability across kernel versions helps reduce the burden of ongoing maintenance, rebuilding effort and repeated validation, while consistency across environments supports long-term deployment in regulated networks.
From conditions to implementation
These conditions define how runtime visibility needs to behave in telecom environments. One place where that visibility can be realized is at the kernel level.
Kernel-level observation provides visibility into process behavior, system calls, and execution context as network functions run. Technologies such as extended Berkeley Packet Filter (eBPF) enable this model when applied within clearly defined boundaries.
Signal capture stays narrow and focused on security-relevant events, while processing and evaluation take place in user space. Kernel interaction is observation-only. It is bounded by the eBPF verifier, so execution paths stay predictable even under load.
This produces a stable baseline where the execution follows known paths, and any deviation becomes visible as it happens without waiting for reconstruction.
Runtime signals in a layered detection system
Runtime visibility adds depth, but intent still depends on how signals are connected.
No single signal source provides the complete detection context. Telecom attacks unfold across multiple systems and planes, with signals appearing in management systems, signaling layers, network functions, platform logs, and traffic observations. Each captures a part of the larger picture.
Layered detection reduces these blind spots by connecting observations across infrastructure, workloads, and network operations into a coherent sequence, improving confidence in both detection and response while limiting false positives.
Runtime signals fit within that model. Combined with network-function telemetry and traffic-level observation, they contribute to events that can be interpreted with sufficient context, without affecting packet handling or execution paths.
Within those limits, detection becomes actionable. Beyond it, security becomes an operational risk.
Nelson Silva oversees endpoint security within Nokia’s NetGuard portfolio for carrier network infrastructure protection. He has more than 25 years of experience in the telecommunications industry, with roles that span network analytics and operations, cybersecurity, global consulting, and product management.
