When should organisations use stronger identity checks for customer servicing and payment activity?

Organisations should raise verification requirements when the action changes account risk, exposes sensitive data, or initiates value movement. Password resets, document access, payment orders, and profile changes are common trigger points. The right control is step-up authentication tied to the transaction, so legitimate users move quickly while higher-risk actions receive more scrutiny.

Why This Matters for Security Teams

Stronger identity checks are not just a fraud control. They are a transaction-risk control that determines whether a user can change account state, move money, or expose sensitive data. In practice, the highest-risk actions are often legitimate requests, which is why step-up authentication should be tied to the action itself rather than applied globally. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats authentication and authorization as control decisions that must match the sensitivity of the event.

The same logic appears in NHIMG research on identity risk. The Ultimate Guide to NHIs notes that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, which is a reminder that identity assurance failures often become business-impacting incidents rather than isolated login issues. For customer servicing and payment activity, weak checks create account takeover paths, unauthorized payment orders, and unsafe profile changes that are difficult to unwind after the fact. In practice, many security teams discover the gap only after a payment dispute, privileged profile change, or fraud event has already forced an expensive containment response.

How It Works in Practice

The practical pattern is to trigger stronger identity checks when an action changes risk, not merely when a session begins. Common step-up points include password resets, new payee creation, payment initiation, contact detail changes, document retrieval, tax or banking record access, and anything that authorizes value movement. The challenge is to balance friction with assurance, so controls should escalate only when the transaction context warrants it.

Most organisations use a tiered model. Low-risk servicing actions may rely on an existing authenticated session, while higher-risk actions require one or more of the following:

• re-authentication with a second factor
• device or session binding
• out-of-band confirmation for payment instructions
• risk-based review when the request is unusual in time, amount, geography, or channel
• step-up approval for sensitive account changes

This is where policy design matters. The strongest programmes evaluate context at request time, including user history, device trust, transaction amount, beneficiary risk, and channel integrity. That makes the decision closer to NIST-style access control than to a simple login gate. It also aligns with NHIMG guidance in the Top 10 NHI Issues, which highlights how identity controls fail when they are static but the action changes. For regulated payment flows, teams often map these triggers to the NIST SP 800-53 Rev 5 Security and Privacy Controls family for authentication, session control, and transaction integrity.

Good implementation also separates identity proofing from session assurance. A customer may be adequately identified at sign-in, but still need a higher assurance check before a wire transfer, new withdrawal destination, or recovery of sensitive records. These controls tend to break down when legacy channels force one verification standard across all requests because the process cannot distinguish routine servicing from high-risk value movement.

Common Variations and Edge Cases

Tighter verification often increases customer friction and support load, requiring organisations to balance fraud reduction against abandonment, accessibility, and service speed. Current guidance suggests using the least disruptive control that still matches the risk, but there is no universal standard for this yet. The right answer depends on the transaction type, the amount at stake, and the organisation’s tolerance for false positives.

Some edge cases need special handling. High-value corporate payments may require dual approval rather than stronger customer authentication alone. Vulnerable customers may need alternative step-up methods if standard MFA channels are unavailable. Assisted servicing desks can also create risk, because an authenticated agent may be acting on behalf of a customer without equivalent assurance. In those cases, the organisation should verify both the caller and the employee action trail.

For payment activity, one-time allowances are usually safer than broad exemptions. If a customer is repeatedly forced through step-up for low-risk actions, the control will be bypassed or abandoned. If a platform under-steps on payee changes or recovery requests, it creates the exact conditions exploited in account takeover and social engineering cases documented across NHIMG research, including the 52 NHI Breaches Analysis. Best practice is evolving toward adaptive, transaction-specific assurance, but organisations still need clear fallback paths for outages, accessibility needs, and high-friction customer journeys.

Related resources from NHI Mgmt Group

• How should MSPs use recurring webinars to improve identity security operations across their customer base?
• How should organisations use identity security events to improve access governance programmes?
• How should organisations use field-level attribute provenance to make identity decisions without overtrusting shared data?
• What breaks when organisations rely on documentation instead of real identity activity data?