Threshold Requirements for authentication means under Regulation 9(a) of the Privacy Protection Regulations (Information Security), 5777-2017

On February 1, 2026, the Protection of Privacy Authority ("The Authority") published a draft regarding the "acceptable means" legally required for identity authentication and access to information.

Regulation 9(a) of the Privacy Protection Regulations (Information Security), 5777-2017 ("The Regulations") requires a owner database to use acceptable means when implementing access permissions to ensure access is limited to authorized persons only, while taking into account the circumstances and the level of security applicable to the database. Regulation 19 also applies this obligation to a database holder. In the era since Amendment 13 went into effect, under section 23(b)(h) of the Protection of Privacy Law, 5741-1981 ("The Law"), financial sanctions may be imposed upon a database owner and database holder who violate this obligation. However, Regulation 9(a) does not specify what those "acceptable means" are, and the Authority seeks to detail them in this draft.

The Authority's draft essentially relies on U.S. National Institute of Standards and Technology (NIST) guidelines. As is standard practice worldwide, there are three possible and common types of authentication:

  • Something You Know: Information known only to the user, such as a password.
  • Something You Have: A physical or digital component in the user's possession, such as an authentication code sent to a mobile phone.
  • Something You Are: Authentication based on physiological or behavioral characteristics, such as a fingerprint template.

A combination of several such means simultaneously is called Multi-Factor Authentication (MFA) and is considered "strong authentication" that verifies the identity of the party accessing the information.

The NIST also defines three main levels of authentication in its guidelines:

  • Authentication Level 1: Authentication by one means; for example: only a "password" of 15 characters, or an 8-character password plus an additional means of identification.
  • Authentication Level 2: Authentication by at least two means, such as a password and an authentication code sent to a mobile phone.
  • Authentication Level 3: Similar to Level 2, but one of the means must be a cryptographic component (such as a smart card).

It is important to note that in each level there are additional nuances and requirements regarding the method of implementation, the "validity" of the authentication means, etc.

In the draft, the Authority added a table meant to “align the level of security applicable to the database and the risks of harm to information security with the required level of authentication”, based on NIST guidelines. However, it appears there is a sweeping inclusion within the manner in which NIST guidelines are implemented in the draft, in such a manner that may burden organizations in the Israeli market in an unjustifiable or unfeasible manner.

According to the draft, when access is granted to an intraorganizational party at all security levels (from databases managed by a single individual to high-security systems), the requirement remains the same: Authentication Level 1, which includes a 15-character password or an 8-character password combined with an additional authentication factor and a password reset every half-year. This is a uniform requirement that is hard to believe will be applicable to a large portion of organizations, and it is doubtful if it is necessary. The minimum requirement of 15 characters for a database managed by a single individual, and in general, is a requirement inconsistent with that acceptable today (8-10 characters). In our opinion, it would have been appropriate to apply this stringency differentially in compliance with the rest of the regulations, including Regulation 9(a) itself, which states that the implementation shall be “under the circumstances of the matter and in accordance with the nature of the database and its quality”.

Second, the Authority initially addressed access to sensitive information ("with high sensitivity") by setting requirements tailored to at least Level 2 security risks. There is doubt whether this is always justified and feasible. In practice, the severity of the stringency regarding Regulation 9(a) blurs the lines of Regulation 9(b), which deals with access to databases with medium or high security levels. Regulation 9(b) stipulates, for good reason, that access to such databases should be based on authentication means "that are as strong as possible", such as MFA, etc. The reason the requirement was formulated as broadly as "whenever possible" is the understanding that not all systems in the market, in all contexts, are required to meet this stringent demand. The draft seemingly aligns with the requirement for databases with medium or high security levels, and it remains to be seen if this is appropriate.

Third, the guideline includes a new requirement that deviates from the regulations: the implementation of an automatic Session Timeout in compliance with the required security level. There is dispute over the importance of this requirement as a common security measure at a technical level. However, it is missing a differential approach. Is a work environment with multiple users the same as someone working on their personal computer? Setting uniform times does not reflect the different material risks between various work environments and could harm usability without providing a proportional security contribution.

Finally, in our opinion, the draft misses an opportunity to amend the existing requirement in the regulations about periodic password changes. The NIST recommended not requiring password changes and focusing on password length and complexity already as early as 2017:

"Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."

This is for security reasons: studies show that requiring high-frequency password changes leads users to choose simple, easy-to-guess passwords.

On the other hand, the Protection of Privacy Regulations and the current draft require password changes every six months. This is an archaic, onerous requirement that has not been updated in view of the new requirement to implement 15 character password length in some cases. The Authority was supposed to clarify that the periodic replacement requirement in Regulation 9(b)(2)(a) would only apply in the appropriate context and in accordance with the chosen password length.

Our position is that a flexible regime is ideal with regard to everything assocaited with managing security measures, setting recommended principles and "best practices" while leaving discretion (and responsibility) to each organization according to its specific context, given data and means at its disposal. This is especially true for dynamic reasons, rapid technological developments, and the importance of the specific context.

Regardless, the draft reflects the Authority's expected position and aligns with the strict and comprehensive approach also reflected by the guidance concerning the implementation of Regulation 10 (keeping and monitoring logs). It is clarified that the requirements apply to all types of employees (regular and admin), suppliers, and customers, in both intraorganizational and extraorganizational connections. Because these are technical changes that may apply to production environments and interfaces, it is recommended that every organization prepare for this now.

The Authority has made this draft available for public comments until February 22, 2026. We invite you to share your insights and comments on the subject with us as soon as possible, which we will be happy to incorporate into our ongoing dialogue with the Authority.

The Privacy, Regulation, and Technology department at Amit, Pollak, Matalon has developed a structured methodology for auditing and implementing privacy, regulation, and technology principles. In this framework, we provide clients with practical tools for ongoing and periodic controls, which help narrowing compliance gaps in organizations and companies operating with us. We also support many of our clients as DPO-as-a-service, ensuring continuous compliance with legal requirements and regulatory changes.

The purpose of this update is to present the innovations in the Protection of Privacy Authority's guidelines and is not concrete legal advice. We remain at your disposal for any questions.

APM Privacy, Regulation and Technology Team.