L'intero punto del meccanismo di scambio di chiavi autenticato da password è quello di abilitare la creazione di un segreto condiviso quando i due le parti non hanno un meccanismo di autenticazione reciproca migliore rispetto a un segreto condiviso a bassa entropia (la password).
Se il cliente può sapere, con una certa sicurezza, la chiave pubblica del server, allora il client può semplicemente usare quella conoscenza per aprire un tunnel sicuro con il server e inviare la password in quel tunnel. Questo è ciò che accade quando un utente umano con un browser Web si connette a un server HTTPS e digita la sua password: il client autentica il server grazie al suo certificato, e questo è sufficiente per attivare un SSL, a quel punto la password può essere inviato "così com'è" poiché il client ha una certa garanzia che stia parlando al server previsto.
Pertanto, se si inizia assumendo che il client conosca la chiave pubblica del server, non è necessario utilizzare SRP. Inoltre, se si assume che il server conosca anche la chiave pubblica del client, non è più necessario utilizzare una password.
Considera la registrazione della password: prima di tale operazione, non esiste un "segreto condiviso" tra client e server. Tuttavia, il cliente utilizzerà in seguito tale conoscenza del segreto condiviso per autenticare il server. Ciò significa che al momento della registrazione deve essere utilizzato un altro metodo di autenticazione, in base al quale il cliente può accertarsi che stia impostando le cose con il vero server.
È possibile immaginare il caso di un client che si registra tramite un'interfaccia Web alimentata tramite SSL (il certificato del server viene utilizzato dal client per assicurarsi che parli al server originale); quindi la password registrata verrà utilizzata successivamente, ad es. da un dispositivo client in cui la convalida dei certificati non può essere effettuata convenientemente.