The enterprise that designs and operates the service should be accountable. Individuals can be vigilant and avoid sharing personal data, but they do not control the authentication methods a business selects. If an organisation chooses weak verification, users inherit the risk. Accountability therefore sits with the provider to select methods that are both practical and harder to abuse.
Why the provider, not the user, owns authentication method choice
Trustworthy authentication is a service design decision, not a consumer preference setting. The business chooses which authenticators it will accept, how much assurance each method provides, and how much abuse resistance it gets in practice. That makes accountability sit with the enterprise that controls the service, the policy, and the fallback paths, not with the individual trying to use the service safely.
The user can only respond to the options presented. If the provider allows weak verification, the resulting exposure is created upstream and then imposed on every account that uses the service. That is why trustworthiness has to be evaluated as part of service governance, not treated as a downstream user behaviour problem. Strong authentication also depends on the broader service design around enrollment, recovery, and step-up checks.
For practitioners, the key question is whether the chosen method can actually resist the abuse patterns the service is likely to face. A method that is convenient but easy to phish, fatigue, reset, or bypass may still be operationally popular, but it does not shift accountability away from the organisation that approved it.
What trustworthy choice means in practice
Choosing well is about matching assurance level to business risk, then making sure the method remains hard to game across the full lifecycle. That includes enrollment, authentication, account recovery, device change, and exception handling. A service can have a strong primary factor and still be weak overall if recovery is poorly controlled or if fallback methods are easier to abuse than the main path.
Provider accountability also means avoiding hidden burden shifting. Users should not be expected to compensate for poor design by spotting phishing, managing secret questions, or performing constant manual verification. The service should make the safer path the default, and the method should be proportionate to the sensitivity of the action being protected.
In identity terms, the right method is the one that reduces both impersonation risk and support-driven bypass risk. If a method cannot be defended after a compromise, or if it can be reset through low-assurance channels, it may be convenient but it is not trustworthy enough for meaningful assurance.
Risk and Threat Considerations
Weak authentication choices create direct exposure because attackers usually target the easiest approved path, not the ideal one. If a provider accepts methods that are vulnerable to phishing, token theft, fatigue attacks, or low-assurance recovery, the service can be compromised even when users behave reasonably. The risk is amplified when the same weak method is used for high-value actions or administrator access.
Failure mechanism: The business approves a method that looks usable but does not hold up against real attack paths, or it adds recovery and fallback routes that are easier to exploit than the primary authenticator. In practice, that turns the provider’s own policy into the weakest link.
Impact: Attackers can take over accounts, abuse trusted sessions, or trigger privileged actions without needing to defeat the user directly. Once authentication is weak, every downstream control that assumes strong identity proof becomes less reliable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack surface, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication and Access Control | Trustworthy authentication methods directly determine access control strength. |
| GV.RM-01 — Risk Management Strategy | The provider must choose authentication based on the service’s risk profile. | |
| Recommendation — Select authentication methods that enforce strong identity proof before granting access. Set authentication assurance levels according to business risk and abuse potential. | ||
| CIS Controls v8 | 6.3 — Secure Authentication and Access | CIS prescribes strong authentication as a practical safeguard for service access. |
| Recommendation — Implement strong authentication and avoid weak fallback methods for sensitive services. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Trustworthy authentication fails when credentials or tokens are weakly managed. |
| NHI-03 — Privilege and Access Governance | Authentication choice affects which identities can be trusted for access. | |
| Recommendation — Manage credentials and tokens with controls that reduce abuse and recovery bypass. Align authentication strength with the access and privilege being protected. | ||
| NIST SP 800-63 | IAL/AAL/FAL — Identity Assurance, Authenticator Assurance, Federation Assurance | This question is fundamentally about who selects assurance-appropriate authentication methods. |
| Recommendation — Choose authenticator assurance levels that match the service’s required trust boundary. | ||
| OWASP Agentic AI Top 10 | A1 — Prompt Injection and Tool Misuse | If authentication governs tool access, weak methods can enable unauthorized actions. |
| Recommendation — Require strong auth before granting tool or action access to automated systems. | ||
Practitioner Guidance
What to verify: Treat the authentication method as a product-level control, not a helpdesk choice. Verify that the selected method is appropriate for the highest-risk action in the service, and that recovery, reset, and exception flows are not materially weaker than the main login path.
Common mistake: Teams often optimise for adoption metrics and support load while underweighting abuse resistance. That can produce a smooth user journey that is still easy to phish, reset, or socially engineer.
Practitioner takeaway: Accountability belongs to the organisation because it controls the assurance boundary. Users can follow the process, but only the provider can choose a method that is both usable and resilient enough for the service’s risk profile.
Related resources from NHI Mgmt Group
- Why do weak authentication methods create fraud risk in digital banking?
- Who is accountable when alternate login methods are left enabled after stronger authentication is deployed?
- Who is accountable when SAP security notes affect authentication and customer-facing services?
- Who is accountable when an identity protocol flaw takes down authentication services?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
