We're a small UK startup building a small service that allows certain special people (e.g. journalists) to access non-public court information.

This information includes a ton of private and sensitive information that cannot just be shared online. From relatively minor things like the name and address of someone accused of doing 31mph in a 30mph zone. But on the other end it also includes e.g. the name, address, age, relatives etc of rape victims, or 12 year old children who have allegedly committed a crime, or children who are potential victims of rape and sexual abuse (or adults who were). This information about protected victims or defendants (which covers sexual crimes and defendants under 18) is illegal to publish, and even illegal to share with the general public (the specifics, the fact that an anonymous case exists in the courts is not illegal to publish).

Anyone who can access this system should be vetted so that they know these laws (e.g. journalists, lawyers, etc), and then it will be their responsibility to use the information legally, and they will hold the liability.

Naturally we want to enforce 2FA on logins. But my question here is whether it's safe to allow devices to be added and remembered for the 2FA? For example Google accounts allow you to tick a box that says this service will be remembered and skip 2FA for a certain time period (1 month iirc).

From the user design point of view it would obviously be better if users were not prompted with a 2FA screen every time they logged in as this delays people and can be frustrating.

In terms of security, is there much of a risk in allowing devices to be remembered for e.g. a month?

Is there anything relating to this with security standards? We will likely have to pass/implement security standards etc before launch, will this effect any of these? E.g. I see ISO 270001 mentioned for similar things, will having the ability to remember 2FA effect this?

3 Answers 3


In this specific case, I would recommend against remembering 2FA. Most of your users will probably ask the browser to save their login and password, so saving the 2FA state will remove a safety barrier.

If someone loses his device (stolen or forgotten somewhere), there's nothing to stop anyone to just log back in and download everything. If you enforce a sensible session inactivity expiration timer (say 15 minutes), and not remember 2FA, even a saved login will not grant access.


Generally, the ISO standards establish a process that will yield secure systems rather than definitively telling you how to build or configure a secure system. They are a helpful foundation in that sense, but they may not provide a specific answer.

Risk assessment is a shared responsibility between all stakeholders. The designer (your firm), the data custodian (government), and the data subjects (UK residents of the relevant jurisdiction) should all be involved in the decision. Since the third party is often impractical to include, a privacy officer or other surrogate will often represent their interests.

A common and reasonable solution would be to authorize devices on a daily basis and permit reauthorization within a one-, eight-, or 24-hour window with a cookie or equivalent mechanism. You can rely on workstation-level security controls such as individual accounts, idle lock screens, etc to reduce the risk of unauthorized access to those sessions if appropriate. This solution implies that the government approves of the design and is willing to require basic security controls from its user community. This must be communicated and documented; until the security implementation is accepted by the customer, it is not "acceptable" regardless of how reasonable it is. (This implies an accepted design and the delivery of a conformant product, as verified by the customer.)

In the EU, there are rules and stiff penalties derived from the GDPR that apply fairly widely, but your customer may not intend to comply with GDPR now that Brexit is happening. Depending on your company and industry, you may want to factor GDPR compliance into the design of your product/modules/libraries anyway, as it can be a major headache if you intend to pursue EU customers later.


There has always been a debate between Convenience and Security. Ans its good to have inconvenience instead of getting the systems/application.

The purpose of two-factor authentication is to double-check the legitimacy of the user, and if we save one of the parameters, I think it is as good as not using it. Two-factor authentication is a must for application processing or storing sensitive information. Ex. PCI-DSS, CSA, etc. The example stated above is a particular case of highly sensitive information. And to reduce the risk, we should use two-factor authentication, without saving any parameter/factor.

Coming to the ISO 27001 standard, it does not recommend whether to use two-factor or not, as it talks about the risk assessment. The control and their depth should be based on the risks (high in this case) identified.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .