Metoda de autentificare ar putea fi luată în considerare. De exemplu, dacă un respondent permite doar colegilor să se autentifice cu autentificarea PSK sau EAP, este destul de inutil să trimiteți orice CERTREQ sarcini utile în IKE_SA_INIT răspuns (deși, nu există nici un rău real în el). În mod similar, este inutil să trimiteți un CERT sarcină utilă la autentificarea cu un PSK.
Spre deosebire de TLS, IKEv2 nu folosește CERTREQs pentru a declanșa/solicita autentificarea cu cheia publică/certificat. Chiar dacă se utilizează autentificarea cu cheie publică, încărcările utile sunt opționale și, de ex. Autentificarea PSK poate fi utilizată chiar dacă este primită o solicitare de certificat (dacă peer-ul o permite).Scopul lor principal este de a ajuta peer-ul să aleagă un certificat dacă are mai multe disponibile (sau de a exprima preferința pentru un anumit tip de codificare a certificatului). Rețineți că unele implementări ar putea să nu trimită certificate dacă nu au primit nicio solicitare de certificat.
CERT încărcăturile utile sunt și ele opționale. Certificatele de entități finale de încredere ar putea fi instalate local sau colegii ar putea folosi chei publice simple care sunt stocate local sau, de ex. preluat prin DNS și validat prin DNSSEC (vezi RFC 4025). Depinde într-adevăr de ce ancore de încredere folosesc colegii și de unde sunt stocate acestea (de exemplu, utilizarea unui PKI va necesita trimiterea de certificate CA intermediare în plus față de certificatul de entitate finală dacă doar certificatul CA rădăcină este de încredere local). Înainte ca fragmentarea IKEv2 să fie specificată (RFC 7383), omiterea certificatelor sau a cererilor de certificat a fost uneori chiar necesară pentru a evita fragmentarea IP a IKE_AUTH mesaj din cauza sarcinilor utile relativ mari.
