Instead of making a protected service ordinarily reachable and then filtering attempts, an SDP system authenticates the requesting identity, evaluates device and contextual signals, and authorizes a specific connection before permitting the requester to reach that service.
An SDP commonly uses a policy controller plus initiating and accepting hosts or gateways. After approval, the enforcement components establish an encrypted path exposing only the allowed application or service — not the surrounding network. This reduces unsolicited discovery and ambient reachability, but “invisibility” is an imprecise marketing shorthand: controllers, gateways, endpoints, and permitted services still have observable and attackable surfaces.
Key points
Access decisionA requester supplies identity, device, and contextual evidence to an authorization component, which evaluates policy before granting narrowly scoped connectivity.
EnforcementInitiating and accepting hosts or gateways restrict the permitted path to approved services and can conceal other addresses and ports from ordinary discovery.
LifecycleDesigns may use single-packet authorization, mutual authentication, short-lived credentials, segmentation, or continuous reassessment; the specific mechanisms vary.
Important limitationAn SDP does not make an unsafe application, compromised endpoint, weak identity process, or poorly protected controller secure. Availability and security depend heavily on the policy, control, and enforcement components, while an authorization decision can become stale as risk changes.