Như đã đề cập ở trên, KS không chỉ chịu trách nhiệm cho việc tạo ra chính sách mã hóa và keys mà còn làm mới keys và phân phối tới GMs. Quá trình gửi keys mới khi key hiện tại sắp hết hạn gọi là tiến trình rekey. GET VPN hỗ trợ 2 loại thông điệp rekey: unicast mà multicast.
Nếu một GM không nhận được thông tin rekey từ KS (KS hoặc đường truyền xảy ra sự cố) thì GM cố gắng đăng kí lại (re-register) để thiết lập kết nối với KSs 60 giây trước khi IPsec SA hết hạn (expire). Nếu đăng kí lại thành công, GM nhận chính sách SAs mới là một phần của quá trình đăng kí lại và lưu lượng trong mặt phẳng dữ liệu không bị gián đoạn. Nếu đăng kí lại không thành công thì GM thử lại 3 lần nữa, mỗi lần cách nhau 10 giây để thiết lập kết nối với KS. Nếu không liên lạc được KS thì GM cố gắng kết nối với COOP KS trong danh sách 20 giây trước khi IPsec SA hết hạn.
Unicast rekey.
KS tạo ra một thông điệp rekey và gửi tối mỗi GM. Khi nhận được thông điệp rekey, GM gửi thông điệp ACK tới KS. Cơ chế ACK này không chỉ đảm bảo rằng danh sách GMs hoạt động trên KS hiện tại mà còn đảm bảo thông điệp rekey được gửi tới GMs hoạt động. Một KS có thể cấu hình truyền lại (retransmit) một gói tin rekey để khắc phục lỗi tạm thời trong mạng. Nếu một GM không nhận 3 rekey liên tiếp thì KS loại bỏ GM từ cơ sở GM đang hoạt động và ngừng gửi thông điệp rekey đến GM.
* Lưu ý: Unicast rekey truyền lại khi GM không thông báo ACK.
Multicast rekey.
Khác với Unicast rekey, khi nhận được thông điệp rekey từ KS nhưng Multicast rekey không có cơ chế ACK. KS không duy trì một danh sách hoạt động GMs.
Ngoài ra, KS có thể cấu hình truyền lại một gói tin multicast rekey để khác phục lỗi giống như Unicast rekey.
* Lưu ý: Multicast phải được kích hoạt trên mạng core cho multicast rekey để hoạt động trên mặt phẳng điều khiển GET VPN.