Start with the action, not the login screen. Basic browsing needs little or no proof, account creation needs contact verification, and sensitive record access needs stronger proof. The governing rule is proportionality: ask for the least identity evidence that safely supports the specific service action, then step up only when the user reaches a higher-risk function.
How should identity proof scale with the service action?
Think in terms of the next action the user is trying to perform, not the page they landed on. A low-risk read-only visit can often be anonymous or lightly identified, while creating an account, changing profile details, or reusing an existing identity profile justifies more evidence because the service is now creating or modifying a relationship that can be abused later.
This is where proportionality becomes a design control, not a slogan. If you ask for high-assurance proof too early, you create friction, abandonment, and unnecessary data exposure; if you ask for too little before a sensitive action, you invite fraud, account takeover, and unsafe record access.
Services that handle patient or customer records should align proofing to the assurance needed for the specific function. A wellness article, appointment lookup, or clinic location search does not need the same identity burden as viewing clinical notes, changing insurance details, or authorising release of records.
What evidence belongs at onboarding versus sensitive access?
At onboarding, the goal is usually contactability and a stable account link, not full proof that the person is already known to the provider. Email or phone verification can be enough when the service only needs to create a basic account, send notices, or support low-risk preferences.
When the user reaches a function that can expose protected data or trigger material change, step up the proof. That may mean stronger identity evidence, a second verification channel, reauthentication, or a separate approval path if the action has irreversible consequences. The important judgement is that the evidence should match the risk of the action, not the perceived importance of the service brand.
For digital health services, this also means separating identity proofing from session control. A user may be properly signed in yet still not be sufficiently established for a new, high-risk function such as record release, proxy access, or profile changes that affect future care delivery.
How do you avoid over-collecting identity data?
Ask for the minimum identity evidence that supports the decision you actually need to make. If the service only needs to confirm a contact route, do not collect document images, biometrics, or unnecessary personal data. If the service needs stronger proof, limit it to what improves assurance rather than gathering broad identity artefacts by default.
A useful design test is whether the same business outcome could be achieved with a lower-friction control. If it can, prefer the lighter option. That keeps onboarding accessible, reduces privacy exposure, and makes the stronger proofing steps more credible when they are genuinely needed.
Identity Proofing and KYC Guide is the right companion when you need to decide which proofing methods fit a given assurance target, especially for account-opening and higher-risk verification steps.
NIST SP 800-63 Digital Identity Guidelines Guide helps teams map service actions to identity assurance, authenticator strength, and federation choices without over-engineering the whole user journey.
Risk and Threat Considerations
Weak proofing at the wrong step creates two different classes of exposure: fraudsters can open or hijack accounts with thin evidence, and legitimate users can be blocked or forced into workarounds that degrade security. In health settings, the harm is higher because access mistakes can expose sensitive records, alter contact details used for care, or enable proxy abuse.
Failure mechanism: The service treats every interaction as if it needs the same identity evidence, or it underestimates the risk of a sensitive action and accepts proof that is only suitable for browsing or low-value account creation. Attackers exploit that mismatch by using the least demanding path to reach protected functions.
Impact: Too little proof can lead to account takeover, unauthorised record access, fraudulent enrolment, and incorrect changes to contact or consent details. Too much proof can push users toward unsafe support channels, duplicate accounts, and avoidable data collection, which can also create operational and privacy risk.
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 OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Level | Identity proofing intensity must match the assurance needed for each service action. |
| AAL — Authenticator Assurance Level | Step-up access needs stronger authentication than low-risk browsing or account creation. | |
| Recommendation — Map each health-service action to the lowest sufficient identity assurance level. Use stronger authenticators only when the action's risk justifies them. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Digital health services often authenticate patients and consumers as external users. |
| Recommendation — Apply external-user identity proofing controls before sensitive patient-access functions. | ||
| OWASP ASVS | V6 — Authentication | The question is about how much proof and step-up authentication a service should require. |
| V8 — Authorization | Sensitive record access depends on the service authorizing the right user for the right action. | |
| Recommendation — Verify that authentication strength increases with the sensitivity of the protected action. Enforce action-based authorization for record access and profile changes. | ||
Practitioner Guidance
Decision rule: Classify each user journey by action, not by page type. If the action only needs contactability, keep proof light; if it can reveal, alter, or transfer sensitive health information, require stronger proof or a step-up control.
What to verify: Check that your strongest proofing is reserved for the few functions that truly need it, and that the service can distinguish browsing, account creation, profile management, and record access without collapsing them into one identity policy. If those paths are blurred, the service will either over-ask everywhere or under-protect the sensitive flow.
Practitioner takeaway: The best identity proof policy is risk-based and action-specific, because the service should only ask for enough evidence to safely approve the next step, not enough to satisfy a generic security instinct.
Related resources from NHI Mgmt Group
- Why does digital identity matter so much in financial services when organisations modernise customer experiences?
- Why do digital identity controls matter so much in eKYC for financial services?
- How should organisations decide how much data to collect when verifying a digital identity?
- How should organisations govern reusable digital identity across multiple services?
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 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org