Private 5G IoT Security: Four Trust Boundaries

Consider a maintenance gateway that joins the correct private network and presents an accepted application certificate. Those checks establish useful facts, but they do not answer whether a recent firmware change was authorized. Nor do they tell the operator which workload will receive the gateway's telemetry. An identity system should not silently become a health monitor. A network firewall should not be expected to establish the integrity of application code. A confidential workload should not inherit unrestricted access just because it runs inside a protected execution environment. The practical starting point is a decision inventory: which fact is being checked, which component can supply evidence for it, and which action depends on the result? Record the gaps explicitly instead of labeling the whole device trusted.

The boundaries below organize an assessment. They are complementary controls, not interchangeable products.

Keep ownership visible. Connectivity teams manage subscriptions; application owners manage service access; platform teams define acceptable measurements; security and operations agree on consequences when a check fails.

A compatible IoT SAFE implementation can give an application access to secure-element cryptographic services. That is useful for device-to-cloud authentication, but it is not equivalent to measuring an entire gateway or proving that its operating system is uncompromised. The GSMA IoT SAFE overview describes the applet and middleware model. Platform evidence belongs in a separate evaluation path. The proposed integration should bind identity records and attestation results to the intended device and session through an authenticated mapping. A serial number copied into two databases is not enough. For example, a maintenance service could require both a current application identity and an acceptable platform result. The operator should be able to explain which requirement failed without guessing from a single red or green indicator.

Some decisions must be made close to traffic: whether a tunnel is expected, whether a request matches an authorized session, or whether a local rate limit has been reached. Broader behavioral analysis can consume selected telemetry and propose later policy changes. Our design recommendation is to avoid turning every packet into a remote analytics request. Give the forwarding path a small, bounded set of checks. Give analytics a separate budget for collection, processing and policy distribution. Apply the same discipline to signaling: authorization and protocol-state checks have a different job from anomaly scoring. Any feedback loop also needs a controlled update path. A useful alert is not sufficient authority to alter access for an entire fleet. Scope updates, validate them, retain a known-good version and make rollback an ordinary operational action.

An unreachable verifier is not the same as evidence of tampering. Similarly, missing analytics does not automatically mean that previously authorized industrial traffic should stop. The correct response depends on the service and the consequence of continued access. Define the policy before an outage: which low-risk operations may continue temporarily, which sensitive actions require a fresh result, and which maintenance channel remains available for recovery. Give any cached decision an expiry and a clearly limited scope. Do not make fail-open or fail-closed a universal slogan. Start validation with disconnected services, expired credentials, stale evidence and rejected policy updates. Measure both the security result and the operational recovery. A proposed architecture is not ready simply because its normal path works.

TeyzSec's focus on hardware-backed attestation and infrastructure trust addresses the question that connectivity alone cannot answer: whether an environment satisfies the policy for sensitive work. The model in this article is a proposed integration approach, not a claim that TeyzSec supplies every cellular provisioning, IoT SAFE or network analytics component. A useful technical engagement starts by identifying the existing identity system, available evidence, enforcement points and workload boundaries. For a first pilot, select one device class and one sensitive operation. Write the acceptance criteria, exercise the failure cases and document the evidence that supports each decision. Expand only after the responsibilities are clear.