Release Notes: https://docs.sophos.com/releasenotes/output/en-us/nsg/sf_185_rn.html
"Old" V18.5 MR1 Thread: https://community.sophos.com/sophos-xg-firewall/f/discussions/128960/sophos-firewall-v18-5-mr1-feedback-and-experiences/
"Old" V18.0 MR5 Thread: https://community.sophos.com/sophos-xg-firewall/f/discussions/127053/xg-firewall-v18-mr-5-feedback-and-experiences
Please review: https://support.sophos.com/support/s/article/KB-000043489?language=en_US
The specific change you mention was a result of a security review we carried out on the OTP functionality. It is not good practice to provide methods to recover existing secrets because this makes it much…
The option to view the QR code of a user's OTP was removed. Can't find this in the release notes. Was quite a surprise for a client use used that option to re-instate changed phones etc.
Resolution/workaround is to delete the OTP and have the user re-create it.
(#2 can't sort release notes by Component to find changes related to a specific feature more quickly - sorting by component not by ID is a bit more human-readable)
The specific change you mention was a result of a security review we carried out on the OTP functionality. It is not good practice to provide methods to recover existing secrets because this makes it much easier to create cloned tokens that could be used without the knowledge of the original user to gain access to their account. Recovering OTP on an account by deleting the existing secret and creating a new one is more secure because even if it is done by the wrong person, the original user will realize the error the next time they try and log in using their old token.
You see the same behaviour in most websites that offer OTP options like this - the only way to recover if you lose your OTP is to re-initialize with a new secret.
Your point about including more specifics about this in the release notes is valid. We try to keep the release notes brief so that customers can read them all quickly and identify areas that may concern them where they can dig in to documentation to find out more. Sometimes we make them too brief. We'll take your feedback into account.
[I updated my original post because I mistakenly thought I was reading the v19 EAP1 forum. Apologies for any confusion.]
That's a high quality answer. Thanks for taking your time!
Going forward, how does one provision SSL VPN users across multiple XGs (for failover/redundancy), with OTP, without access to the OTP secrets? Will this require a user to have separate OTPs for each firewall?