A GPG45 confidence level is the assurance target assigned to an identity check based on the risk of impersonation or fraud. It helps an organisation choose how strong the verification process needs to be, rather than applying one fixed standard to every onboarding journey.
What the confidence level means in practice
A GPG45 confidence level is not a score of “truth”, it is a decision about how much assurance an organisation needs before accepting an identity check. It exists to match verification strength to the risk of impersonation or fraud in a specific onboarding flow.
That matters because a single verification method is rarely suitable for every use case. A low-risk journey may need only a modest level of evidence, while a higher-risk account opening or regulated service may require stronger checks, more corroboration, or additional review.
How GPG45 turns risk into an assurance target
The main value of the confidence level is that it translates business risk into a practical verification target. Instead of asking whether an identity check was “good enough” in the abstract, the organisation can ask whether the process reaches the confidence needed for that journey, product, or customer segment.
This makes GPG45 useful for standardising decision-making across onboarding teams, vendors, and channels. It also helps reduce a common failure mode, where one verification path is reused everywhere even though the exposure, fraud appetite, and regulatory expectations are not the same.
When teams apply the concept well, the confidence level becomes a design input for evidence collection, checking depth, exception handling, and escalation thresholds rather than a retrospective label attached after the fact.
What it does not tell you
A confidence level should not be treated as a complete judgment on the person being verified. It says how strongly the process supports the identity decision, not whether every possible risk has been eliminated.
It also does not replace wider controls such as fraud monitoring, account takeover detection, sanctions screening, or ongoing account protection. A strong initial check can still be undermined later if the account recovery process is weak or if session and change controls are poor.
For that reason, the confidence level is best understood as one control point in a broader identity assurance and fraud control model, not as the whole security outcome.
Using confidence levels alongside verification methods
In practice, the confidence level helps an organisation decide how much evidence, corroboration, and review is needed from the verification method it chooses. A simple document check, for example, may be acceptable for one risk tier but insufficient for another unless it is paired with stronger evidence or additional checks.
That is why teams should design the journey around the required assurance target first, then select the method mix second. The result should be a consistent policy for when automation is enough, when human review is needed, and when the case should be escalated for further scrutiny.
Good use of the concept also supports auditability. When an onboarding decision is challenged, the organisation can explain why the chosen verification path matched the expected confidence level for that specific risk.
Risk and Threat Considerations
Weakly matched confidence levels create a straightforward fraud and impersonation problem: the organisation may accept an identity check that is easier to fake than the journey actually requires. Overly aggressive settings create the opposite problem, blocking legitimate users and pushing them toward workarounds or abandonment.
Failure mechanism: Attackers exploit under-calibrated verification flows, especially where the same assurance threshold is reused across journeys with very different fraud exposure, recovery paths, or account value.
Impact: The result can be synthetic identity acceptance, account opening fraud, downstream account takeover, or unnecessary friction that harms conversion and operational efficiency.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | GPG45 confidence levels map to identity assurance strength and verification confidence. |
| Recommendation — Align identity proofing and verification depth to the required assurance level for each journey. | ||
| NIST SP 800-53 Rev 5 | IA-12 — Identity Proofing | Identity checks and confidence targets are driven by proofing strength and fraud resistance. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Customer-facing identity verification is a non-organizational user authentication and assurance problem. | |
| Recommendation — Set proofing requirements to match the fraud risk of the account or transaction. Use appropriate authentication and proofing controls for external users based on risk. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Identity assurance supports controlled access decisions and onboarding governance. |
| Recommendation — Apply access policy rules that match the assurance level needed for the service. | ||
| CIS Controls v8 | CIS-5 — Account Management | Verification confidence affects how safely accounts are created and accepted. |
| Recommendation — Tie account creation controls to the identity assurance needed for the account type. | ||
Practitioner Guidance
Why practitioners should care: Treat the confidence level as a policy decision, not a documentation detail. It should be set from the risk of the journey, the harm from impersonation, and the consequences of false acceptance or false rejection.
Common misunderstanding: A higher confidence level is not automatically better. The right target is the one that fits the use case and can be defended consistently across channels, suppliers, and exception paths.
Practitioner takeaway: Define the confidence target before choosing the verification method, then review whether the process actually produces evidence strong enough to justify that target.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org