Security Key Service
In OPC UA, a Security Key Service is the component that distributes the symmetric group keys PubSub uses to sign and encrypt messages. PubSub has no session and no handshake, so there is nowhere to negotiate keys: publishers and subscribers instead fetch keys for a named SecurityGroup from a common SKS.
Why it has to exist
In client-server OPC UA, OpenSecureChannel authenticates both certificates, exchanges nonces and derives per-channel symmetric keys. PubSub deliberately has none of that: a publisher transmits to a multicast address or a broker topic with no idea who is listening, and cannot perform a handshake with an unknown and variable set of subscribers. The only workable model is a shared group key handed out by a trusted third party, which is what an SKS is.
Pull and push, and what a key set contains
In the pull model a publisher or subscriber calls GetSecurityKeys on a remote SKS - itself an ordinary OPC UA server, reached over a normal authenticated secure channel - naming the SecurityGroupId it needs. In the push model the SKS writes keys into the participant's configuration. Either way the response is a current key plus a list of future keys with a time-to-next-key, so participants can roll over without a gap. Keys are per SecurityGroup, and a WriterGroup references its group by SecurityGroupId.
What the keys protect
PubSub message security is AES-128-CTR or AES-256-CTR for confidentiality with HMAC-SHA-256 for integrity, plus replay-window checking against the message sequence number. Signing alone authenticates the publisher and keeps traffic readable to a packet capture, which is often what you want on a closed cell network; encryption additionally hides the payload from anyone on the multicast group or the broker topic. Note that group keys authenticate the group, not an individual publisher: anyone holding the key can publish.
Deployment reality in 2026
A server that offers the service advertises the capability code SKS in its discovery registration, and the natural host is a Global Discovery Server, since it already holds application identities and trust. In practice most PubSub deployments in the field run with security mode None and rely on network segmentation, VLANs and broker-level TLS instead. That is a defensible choice on an isolated cell network and an indefensible one on a shared plant network.
Example
Who talks to whom - the SKS link is ordinary client-server, the PubSub link is not
Publisher --- opc.tcp secure channel ---> SKS server (GetSecurityKeys, SecurityGroupId "sg-cell3")
Subscriber --- opc.tcp secure channel ---> SKS server (same SecurityGroupId, same keys)
Publisher === opc.udp://239.0.0.1:4840 ==> Subscriber
UADP, signed/encrypted with the group key - no handshake, no reverse path
Discovery registration of the SKS host advertises capability code: SKSDefined in: Part 14 - PubSub, security and key distribution; Part 12 - Discovery and Global Services for the SKS host.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.