'Don't ask for MFA' reverting after 60 mins

[SNAdmin47]

Hi, 

We use MFA for external customers which works fine but we've recently noticed that when the 'Don't challenge for MFA on this browser for the next 8 hours' tickbox is ticked it only works for 1 hour, i.e., it won't challenge for MFA for the first hour but will then revert and challenge for MFA after 1 hour has passed. As per the MFA properties product doc I've checked the sys_property 'glide.authenticate.multifactor.browser.fingerprint.validity' and this is set to 8 which should be effective for 8 hours, and the sys_property 'glide.authenticate.multifactor.remember.browser.enable' is also set to true: https://www.servicenow.com/docs/bundle/utah-platform-security/page/integrate/authentication/referenc...

Is anybody able to confirm if this is expected behaviour or if there's potentially something else I can check or refer to to restore the 8 hour MFA fingerprint validity? Our session timeout is set to 60 mins, so I was wondering if that has an impact but it seems unlikely since I've tested on our dev instance and reduced the session timeout to 5 mins and it worked fine. 

Many thanks in advance, any help would be greatly appreciated!

[Shivalika · Accepted solution]

Hello @SNAdmin47 

Sure, do let me know.

Kindly mark my answer as helpful and accept solution if it helped you in anyway,

Regards,

Shivalika 

My LinkedIn - https://www.linkedin.com/in/shivalika-gupta-540346194

My youtube - https://youtube.com/playlist?list=PLsHuNzTdkE5Cn4PyS7HdV0Vg8JsfdgQlA&si=0WynLcOwNeEISQCY

[Simon Christens]

I think you are right in this case.
MFA (session info) is kept in cookies and depending on how the browser handles the cookies it will impact how it works.
I have inconsistency in Brave as well. This week it seems alot more "stable" though than last week where it dropped the session often as well.
So if the open browser some how "drops" the session - like if you close the browser and reopens it - the result will be the same and you need to use MFA again to get access.
So I agree that this is more likely a browser issue than a SN issue.

[Ankur Bawiskar]

@SNAdmin47 

What was the outcome for this?

[SNAdmin47 · Accepted solution]

Hi @Ankur Bawiskar  My colleague still has an open ticket for it and is still awaiting feedback from the business stakeholders, but we've advised them that from the disparity in our testing with different browsers, and also using different security settings and versions on browsers, we believe this is most likely due to browser configuration. 

[Ankur Bawiskar]

@SNAdmin47 

Then please mark your own response as correct so that it helps future members.

The answer marked as correct might not help future members.

[SNAdmin47]

Hi @Ankur Bawiskar , Done.... Truth be told I considered doing so previously but as we didn't have a definitive confirmation that our suspicions were correct and since the issue is still outstanding with the business I didn't want to over-commit and mislead others. However, with this additional note added to heavily caveat that is the case, then that should provide enough insight for others.