PR stands for Privileges Required. In CVSS 3.1 it records the access an attacker must already hold before exploiting a flaw: None means unauthenticated, Low means a basic user account, High means administrative control. A PR:N finding is reachable by anyone who can reach the component, so it usually ranks higher.
The three values
The 3.1 specification defines them this way.
| Value | Vector text | What the attacker needs first |
|---|---|---|
| None | PR:N | No authorization at all |
| Low | PR:L | Basic user capabilities that touch only that user's own settings and files, or non-sensitive resources |
| High | PR:H | Significant control, such as administrative control over component-wide settings and files |
The metric describes the attacker before the attack starts. It does not describe what they gain afterwards. That is covered by the impact metrics at the end of the vector.
Reading it in context
Take two vectors that differ only in PR:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
The first needs nothing. The second needs an administrator account. In the first case an outsider is the threat. In the second, the realistic threat is a compromised or malicious admin, or an attacker who has already won a different fight. The scanner's severity label treats them very differently because the numeric constants differ: 0.85 for None against 0.27 for High when scope is unchanged.
A short decision routine
- Find PR in the vector.
- Ask who in your environment holds that privilege level. For PR:H, list the accounts. If the list is two trusted operators, the finding is less urgent than the label suggests.
- Ask how an attacker could obtain it. Credential theft, an unrelated bug or a shared admin login can all bridge the gap, so PR:H is a discount, not a dismissal.
- If PR:L, look at how accounts are created. Open sign-up turns Low into effectively None for your product.
That last point matters. A scanner cannot know whether anyone can register an account on your service. You can, and the answer moves the finding up or down.
Common mistakes
- Reading PR:L as "needs a login, so safe". If registration is open, the barrier is a form.
- Reading PR:H as "ignore". Chains of bugs routinely start from a low-value foothold.
- Comparing PR in isolation. Always read it with Attack Vector and User Interaction. PR:N plus AV:N plus UI:N is the widest door in the model.
- Forgetting that scope changes the constants. The specification gives Low as 0.62 unchanged and 0.68 changed, and High as 0.27 unchanged and 0.5 changed.
Recording your reasoning
Write one line in the ticket: who holds the privilege in your system and how it can be obtained. That line is what an auditor or a teammate will want later, and it turns a generic vector into a decision specific to your service.
Safeguard's policies and gates let you set rules on severity and other signals so that a CI check reflects how your team reads these vectors, and a free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Open a finding and compare its severity with the context around it.
Quick check
Is PR:L the same as needing a login?
Roughly, but the real question is how easy it is to get that account. If anyone can sign up, a Low privilege requirement offers little protection.
Does PR describe what the attacker gains?
No. PR describes access needed before the attack. The gain is described by the confidentiality, integrity and availability metrics.
Sources
Last reviewed: 19 October 2026.
