Clause 1
- Public status
- The scope is in the public preview and is quoted in our own words below.
- Binding party
- The organisation that derives a cryptographic key from a human-memorised password, and anyone asked to show that its derivation follows this part.
- Evidence
- 3 items
- Read
- 2026-10-21
The register / Clause 1
Scope
This part covers one narrow family: functions that turn a human-memorised password into a cryptographic key. It applies where a key has to be produced from a password.
Our reading
The scope is deliberately narrow. It is about producing a key for another algorithm or application, not about storing a password so that a login can be checked. A product that hashes a password for verification only, and never uses the result as a key, is outside this scope on the face of clause 1.
The first clause settles the question every reader asks first: is this standard about me? It answers with one sentence of substance. The document covers key derivation functions built for human-memorised passwords, and it applies where a cryptographic key must come out of a password. Everything else in the document serves that job.
That boundary matters because the market uses the words loosely. A login form that stores a password hash is not deriving a key for another algorithm. A backup tool that turns a passphrase into an encryption key is. A password manager that wraps a vault key with a master password is. A device that provisions a network key from a printed password is. The test is what the output is used for, not which library produced it.
The clause also explains why a separate part exists at all. The rest of the key management series deals with keys generated from random sources or established between parties. A password is neither. It has little entropy, it can be guessed, and the derivation has to be made expensive on purpose. That single property changes the design, the parameters and the evidence an assessor will ask for.
Read the scope with the introduction. The introduction accepts that passwords remain widely used and that deriving a key from one is sometimes necessary. The document does not ban the practice. It gives two functions that are meant to make guessing attacks costly, and it expects the choice and the parameters to be handled carefully. That is a build and assurance job, not a paperwork job.
The mistake to avoid
Treating every password hash in the estate as if it were a key derivation function. The scope turns on the purpose of the output.
Evidence to keep
- A one-page scope memo that names each password-derived key and the algorithm or store it protectsShows the boundary was decided from the use of the output, not from the library in use.
- A list of password verification paths that are excluded, with the reasonLets an assessor see that the exclusion was deliberate and not an omission.
- The data flow from password entry to derived key to protected assetProves the key exists and is used as a key, which is what brings the work into scope.
Test it
Name one place where a password-derived value is used as a key for another algorithm, and one place where a password is only verified. If the two cannot be separated, the inventory is not ready.
Dates
| Date | What | Basis |
|---|---|---|
| 2027-02-16 | Expected publication, an estimate | Planning date 120 days from the scout date, derived from stage 50.20. ISO has published no publication date. |
Cross references
- ISO/IEC 11770-1:2010, framework
- ISO/IEC 11770-4:2017, mechanisms based on weak secrets
Source
https://www.iso.org/standard/87940.html
Read on 2026-10-21. The scope is in the public preview and is quoted in our own words below. ISO free public preview carries the foreword, the introduction, clauses 1 to 3 and the table of contents. It is the DIS, not the FDIS, and the FDIS may differ. Clauses 4 to 7, annexes A to D, the figures and the object identifiers are not in the free preview; ISO sells the text. This site does not reproduce it and does not invent it.