This is a summary of our current understanding of the impact of the Chrome SameSite change that has been well-publicized, and is due to appear in Chrome 80 on February 17, 2020has been released by Chrome and by Firefox as of 2022.
While this page discusses the direct implications of this change on the operation of the SP software, the fact is that the bulk of the concerns in most cases lie within the application space and are not going to be remedied by anything here. Nor can we provide any sort of yes/no or good/bad conclusion for anybody as to whether "their system is affected". That is going to depend entirely on the individual case and the only real answer is to test.
Firefox is generally the most effective way to test this because its hidden settings will take effect instantly and do not include the 2 minute grace window that Chrome uses, so you can see the real impact of the change quickly.
The SP is impacted in four primary ways because it uses cookies in four significant ways. See also the CookieUsage topic.
All of these cookies can be controlled with the cookieProps setting and given a SameSite=None attribute, but that will break all non-current Any supported SP version automatically adds the SameSite value needed to the cookies that require it. You do not need to, and should not, adjust the cookieProps setting to do this.
However, the automatic behavior will break older macOS and iOS Safari browsers. We do not encourage using that at this time because an update is planned that will provide more fine-grained control with appropriate workarounds, and the sameSiteFallback setting (see Sessions) was created to address that. Another setting, sameSiteSession, allows the session cookie itself to be "unlocked" for cross-site use, but as noted below, this is generally a bad idea and is not needed for the SP itself to function.
Finally, note that a typical source of problems for most applications is going to be load balancer behavior. If you're using cookies for node affinity, you're going to have problems with SameSite unless you do something about it.
...
There is at least one, and possibly two (if the optional recovery feature is enabled), cookies created to track each session. These cookies are created only after the form POST is delivered from the IdP, and so are technically not cross-site in the general sense. In most cases, they do not need to be marked SameSite=None, and in fact to do so is to defeat the entire rationale behind the change Google is making.
...