What breaks when universities trust password login for direct deposit changes?

Why password login fails at the payroll change point

Password login only proves that someone knew a secret, not that they are the employee who owns the salary destination. That distinction matters at direct deposit change time because the action is high impact, hard to unwind, and often processed before the next pay cycle. The portal is usually doing authentication, but the business decision needs stronger identity proofing for the change itself.

Universities often underweight this because the workflow looks routine: the same user signs in, updates a profile field, and the system accepts the request. In practice, the control failure is not the login screen, it is the assumption that authenticated session equals legitimate payee change.

When that assumption breaks, the attacker does not need to defeat payroll processing or internal finance controls. They only need one stolen password, one unattended session, or one reused credential to reach the self-service change path.

What the attacker actually exploits

The attacker is exploiting a trusted administrative action disguised as a normal employee self-service function. Once inside, they can alter the destination account, wait for payroll to run, and then collect funds through a channel that may look valid to downstream systems.

This is why the weak point sits at the moment of change, not at payment execution. The bank transfer may be technically correct from the payroll system’s perspective, while the underlying request was fraudulent from the employer’s perspective.

That makes the attack attractive: it is low noise, fast to execute, and often discovered only after the employee expects a missing paycheck. The portal’s convenience becomes a direct fraud path when the change request is not re-verified.

What universities should treat as the real control gap

The control gap is lack of step-up verification for a sensitive account update. For a direct deposit change, the organisation should distinguish ordinary portal access from an action that changes where money goes, because those two events have very different risk levels.

Good designs confirm the request with a stronger factor or out-of-band approval before the record is updated, and they create a clear audit trail for who requested, approved, and completed the change. A change of payee destination should be treated like a high-risk account recovery or payout instruction, not a routine profile edit.

That also means access reviews and help desk escalation paths matter. If payroll support can override the portal without robust verification, the attacker may simply move to the weaker path.

Risk and Threat Considerations

Direct deposit changes concentrate fraud risk because they combine authentication, financial redirection, and time delay before detection. A compromised password can create immediate exposure, but the business impact often appears only when the next payroll run completes and the false destination receives the money.

Failure mechanism: The portal accepts ordinary login as sufficient proof for a payout-direction change, so a stolen or reused credential lets an attacker modify bank details without proving ownership of the payee instruction.

Impact: The organisation can suffer wage diversion, employee harm, payroll rework, support load, and dispute handling, while recovery may be limited once funds are paid out.

Practitioner Guidance

What to verify: Confirm that a bank-detail change requires more assurance than a standard login, and that the verification method is bound to the change event, not just the account session. If the same password unlocks both portal access and payout changes, the control is too weak.

Decision rule: If the request changes where funds are sent, require step-up validation and logging that can support later dispute review; if the request only changes a low-risk profile field, standard portal controls may be enough.

What practitioners underestimate: The harm is not only theft, it is the lag between compromise and discovery. The best indicator of good control is that a fraudulent change becomes difficult to complete quietly, easy to investigate, and fast to reverse before payroll closes.

Practitioner takeaway: Treat direct deposit edits as payment-authority changes, not account-maintenance events, and design the workflow so a stolen password cannot by itself redirect salary.

Related resources from NHI Mgmt Group

• What breaks when Zero Trust only covers login and privileged access?
• How should universities stop direct deposit fraud when credentials are stolen?
• What do institutions get wrong about direct deposit changes?
• What breaks when organisations rely on login success as proof of trust?