The first push is started at the time a SecurityGroup is assigned to the PubSubKeyPushTarget. The assignment is done with the Method ConnectSecurityGroups or with a successful update of the PubSubKeyPushTargets with PubSubConfigurationType CloseAndUpdate. The sequence for push is described in 5.4.4.3.

In a period of half the KeyLifetime of a SecurityGroup, the SKS shall open a secure communication to each related PubSubKeyPushTargets and shall call SetSecurityKeys to push the security keys for a SecurityGroup into a Publisher or Subscriber. The SKS shall push the previous security key, the current key, and at least one future key to bridge longer unavailability time of the SKS. If it is not possible to push security keys to a PubSubKeyPushTarget due to errors in establishing the communication or due to errors returned from the SetSecurityKeys Method call, the SKS shall retry pushing the security keys in a period of RetryInterval. If multiple future security keys are pushed, it is up to the SKS to define when security keys are pushed, but at a minimum it shall be at the half KeyLifetime of the current key when only one future key is remaining.

Since the SKS is unaware of the state of a PubSubKeyPushTarget, it is recommended for a PubSubKeyPushTarget to persist security keys. This allows the PubSubKeyPushTarget to continue secured PubSub communication after a power cycle, as long as the outage time is smaller than the time covered with currentKey and FutureKeys. If keys are not persisted, it may take up to half the KeyLifetime to get the first set of security keys. The PubSubKeyPushTargets persisting security keys shall have an understanding of time (either synchronized or battery backup) allowing them to determine whether the current key is still valid to use, or whether to use a future key following a power interruption.