We should definitely change to per peer PSKs.
Following Storömberg's observations, the following points
may also be worth considering:
1. Partial deployment
Per peer PSK allows organization to deploy PSK to a subset of
peers and have a smooth transition should they wish to implement
it later.
2. Compromise of endpoints
All it takes is one compromised endpoint and PQ secrecy fails
completely.
If an employee ever leaves his laptop unencrypted and unattended,
the PQ secrecy of all the corporations VPN
connections could be lost.
Furthermore, if an administrator suspects this may be the case,
he has to deploy new keys to all endpoints in a PQ secure manner
(e.g sending them over HTTPS is meaningless);
he most likely has to physically install the new PSK on every
client!
In case of compromise, the peers public key must be updated
regardless and updating the per peer PSK along with it seems a
manageable task.
3. Disclosure of data under a warrant
Suppose the organization deploying Wireguard is
forced to decrypt the data to/from a single peer.
Currently this is not possible, because of forward secrecy,
however in a post-quantum setting it would be.
Limiting the disclosure to a single peer is substantially harder
with a globally shared PSK.
Periodically rotating the PSKs and completely avoiding the
case above is much easier if the PSK is per peer.
4. Public VPN
If Wireguard is deployed as a public VPN, there is no hope of
PQ security with a global PSK.
In the case of a per peer PSK, this may be achieved by meeting in
person or exchanging the PSK with PQ crypto, e.g
the overhead of McEliece may be acceptable, since the PSK is only
transfered once.
5. Users and secrets
Since the key is shared, you can count on Alice asking Bob for his
VPN configuration,
you can also count on Bob sending said configuration over email.
Again the PQ security for the entire organization is lost.
As the organization grows, the probability of such an event goes
to 1.
Regards,
Mathias