Yes, security standards benefit from RFC 2119 keywords. MUST marks an absolute requirement, SHOULD marks a strong recommendation with room for justified exceptions, and MAY marks something optional. State that you are using them, write them in capitals, and use them sparingly.
What RFC 2119 says
RFC 2119 is a short internet standard, published in 1997, that defines how to read a set of capitalized words. Per the text:
- MUST, REQUIRED and SHALL mean the item is an absolute requirement.
- MUST NOT and SHALL NOT mean it is an absolute prohibition.
- SHOULD and RECOMMENDED mean there may be valid reasons to ignore the item, but the full implications must be understood and the case carefully weighed first.
- MAY and OPTIONAL mean the item is truly optional.
The RFC also tells authors to use these words with care and sparingly. They should appear where needed to limit behavior that could cause harm or break interoperation.
Why it helps in security documents
Security standards often fail on ambiguity. "Services should use encryption" can mean anything from a hard rule to a nice idea. With defined keywords:
| Draft | Reads as |
|---|---|
| Services MUST encrypt data in transit | A hard rule. An exception needs a recorded approval. |
| Services SHOULD pin dependency versions | A default. Deviation needs a stated reason. |
| Teams MAY use an alternative scanner | Optional. No approval needed. |
Reviewers and engineers then argue about the rule itself, not about what the verb meant.
How to adopt it
- Add one line near the top of the standard: that the keywords are used as described in RFC 2119 and are capitalized when they carry that meaning.
- Review every "must" and "should" in the draft. Capitalize the ones you mean in that sense.
- For each MUST, add how to verify it. If you cannot verify it, soften it or build the check.
- For each SHOULD, say what a valid reason looks like, and where to record it.
- Keep the lowercase words for ordinary prose.
Mistakes to avoid
- Everything is a MUST. Engineers learn to ignore the word. Save it for rules you will enforce.
- SHOULD as a polite MUST. If no exception will ever be accepted, say MUST.
- MUST in a guideline. A guideline allows judgment by definition. See which security document to write.
- No exception path. A MUST without a way to record a waiver pushes people to ignore it quietly.
Link the rule to enforcement
A MUST that can be checked by a machine should be. Pipeline checks, merge gates and admission controls turn a sentence into behavior. Safeguard policies and gates can do this for dependency rules on pull requests, and the pull request gate demo shows what that looks like.
Sources
Quick check
Do I have to capitalize the words?
The convention is to capitalize them when you mean the RFC 2119 sense, so readers can tell rules from ordinary prose.
Is RFC 2119 meant for protocol specifications?
It was written for them, but many teams borrow it for internal standards because the definitions are short and widely understood.
Last reviewed: 19 October 2026.
