Key Takeaways

  • Adnovum: Financial institutions allocate roughly 10-14% of IT budgets to cybersecurity. Buyers should tie that spending to measurable outcomes in fraud prevention, regulatory compliance, and service availability.
  • A useful evaluation tests phishing-resistant FIDO2 authentication, OAuth 2.0 token controls, endpoint telemetry, and distributed denial-of-service (DDoS) response against representative banking workflows.
  • A phased rollout can move access reviews from spreadsheets to identity-governance workflows aligned with NIST Cybersecurity Framework 2.0 and ISO/IEC 27001:2022. Extending those controls to custom and legacy banking systems often requires specialized application integration.

Why Banks Need Cyber Resilience

A corporate customer signs in from a managed laptop, approves a high-value payment, and then switches to a mobile device. Behind that ordinary transaction, a bank may evaluate the device certificate, session token, IP reputation, behavioral signals, payment limits, and sanctions controls in seconds.

Security failures in that chain affect more than the security operations center. They can interrupt customer access, delay payments, create regulatory reporting obligations, and produce audit findings that require months of remediation.

The investment reflects those stakes. According to Gartner research from 2025, financial institutions consistently lead other industries in security investment, allocating approximately 10-14% of their IT budgets to cybersecurity, compared with an average of 9.8% across sectors. The same research placed sector spending at about 0.8-1.0% of revenue. Separately, Gartner’s worldwide market forecast projected information-security end-user spending of $212 billion in 2025, while its 2026 outlook puts global spending at roughly $240 billion. That global vendor-market forecast covers security software and services, so its scope differs from an individual bank’s budget ratio.

Threat exposure remains elevated. The finance-specific ENISA Threat Landscape: Finance Sector identified finance as one of Europe’s most frequently targeted critical sectors and found that banks were the primary target between January 2023 and June 2024. DDoS activity, data breaches, and credential-based compromise were prominent in that historical sector analysis. For a newer cross-sector baseline, the ENISA Threat Landscape 2025 confirms that availability attacks, intrusion activity, and data threats remain material operational concerns.

Consider a composite regional bank running Microsoft Active Directory, an Okta identity tenant, a mobile banking application, and payment services hosted across private infrastructure and Microsoft Azure. Quarterly access reviews arrive as CSV exports. Analysts compare them manually with HR records and application-owner lists, while incident responders move between endpoint alerts, firewall logs, and payment-monitoring cases.

That is expensive friction. It also obscures whether a disabled employee account still holds an OAuth refresh token or an administrator retains access to an application connected with the Society for Worldwide Interbank Financial Telecommunication (SWIFT).

How to Evaluate Financial Security Products

The bank’s evaluation began with transaction paths rather than a feature checklist. The team documented how retail login, employee administration, privileged maintenance, and third-party support sessions moved through SAML 2.0, OpenID Connect, OAuth 2.0, and legacy LDAP connections. SAML and OpenID Connect exchange authentication information between systems, OAuth delegates access through tokens, and LDAP provides directory access for many older applications.

Products from Palo Alto Networks, CrowdStrike, and Okta were assessed for network telemetry, endpoint protection, identity controls, and session enforcement. The bank also involved Adnovum when examining how security controls would interact with custom banking applications and existing software-maintenance processes.

Architecture decisions were mapped to the official NIST Cybersecurity Framework 2.0, with financial-services requirements applied to its Govern, Identify, Protect, Detect, Respond, and Recover functions. ISO/IEC 27001:2022 established a complementary information-security management structure for risk treatment, supplier access, logging, and audit evidence.

The practical test was whether each product could enforce policy at the relevant point. For workforce access, that meant FIDO2, a passwordless authentication standard based on public-key cryptography, through security keys or passkeys rather than SMS codes. For privileged administration, it meant just-in-time access with approvals recorded in the identity-governance system. For application programming interfaces (APIs), it meant short-lived tokens, audience restrictions, key rotation, and revocation that did not depend on waiting for a user password reset.

How to Implement Identity and Security Telemetry

During discovery, a joint team of security architects, identity engineers, application owners, compliance specialists, and fraud analysts built a service inventory. They traced authentication and authorization across the core banking platform, customer portal, mobile API gateway, Microsoft 365, payment operations, and the security information and event management (SIEM) platform. A SIEM centralizes and correlates security events from multiple systems.

The initial rollout covered employees with elevated access. FIDO2 authentication was introduced for administrators, while privileged sessions were routed through a hardened access service and recorded for review. CrowdStrike endpoint events and Palo Alto Networks firewall telemetry were forwarded through syslog and REST APIs into the bank’s SIEM, where correlation rules connected suspicious logins with endpoint and network activity.

Midway through implementation, the team found that several older applications accepted SAML assertions but could not process modern conditional-access signals. Replacing those applications immediately was impractical. Adnovum therefore participated in the application workstream that placed an authentication proxy in front of selected systems, translating modern identity policy into headers and session controls the older applications could consume.

Token handling created another obstacle. Disabling an account in Active Directory did not instantly invalidate every cloud session. The identity team shortened refresh-token lifetimes for sensitive applications, added risk-based reauthentication, and connected employee termination events from the HR platform to identity-revocation workflows.

Granted, shorter sessions can irritate users. The bank limited stricter settings to privileged consoles, payment approval, and customer-data administration rather than forcing frequent prompts across low-risk collaboration applications.

What Outcomes Can Security Modernization Deliver?

The organization reported that access certification moved from emailed spreadsheets to application-owner queues with recorded approvals, timestamps, and escalation rules. Reviewers could see an employee’s department, manager, entitlements, and last-use data in one workflow instead of reconciling several CSV files.

Incident responders also reported faster investigation because identity, endpoint, firewall, and API gateway events shared a user identifier and Coordinated Universal Time (UTC) timestamp. A suspicious login could be examined alongside device posture, token issuance, outbound connections, and payment activity in the SIEM.

For customers, phishing-resistant authentication and risk-based session controls reduced reliance on reusable passwords without applying the same friction to every interaction. The organization has not disclosed specific customer-loss reductions, incident percentages, or financial returns, so these outcomes represent observed operational changes rather than audited performance claims.

DDoS preparation became more concrete as well. DDoS attacks attempt to make an online service unavailable by overwhelming it with traffic. The bank defined DNS failover, traffic-scrubbing activation, rate limits at the API gateway, and runbooks for preserving balance inquiries and payment-status checks when less critical functions were restricted.

Financial Security Implementation Lessons

The legacy SAML issue demonstrated why product demonstrations are insufficient. Testing against an older application uncovered missing conditional-access support before broad deployment, prompting the use of an authentication proxy instead of an unplanned replacement project.

The token-revocation gap changed the offboarding design. HR events, directory suspension, OAuth session revocation, and privileged-vault removal were treated as one workflow because disabling a directory account alone left active sessions elsewhere.

The bank also learned to separate customer friction from control strength. Applying FIDO2 and tighter session lifetimes to payment administrators delivered a clearer risk reduction than imposing repeated authentication prompts on every office application.

Financial Security Use Cases and FAQs

Insurers, payment providers, and mid-market lenders can adapt this model by starting with a limited set of high-consequence journeys, such as claims payments or treasury administration. A PostgreSQL-backed service inventory, REST-based log integration, and FIDO2 rollout can provide useful coverage before a broader platform replacement. The implementation sequence and lessons from legacy integration offer a starting point for planning.

How long does a financial security implementation take?

A focused identity and telemetry deployment often spans several months, depending on application count and legacy protocols. Organizations should reserve separate phases for service discovery, a limited privileged-user rollout, application integration, and operational handoff rather than treating software installation as completion.

What should a bank test during a security product evaluation?

Test FIDO2 authentication, OAuth token revocation, SAML compatibility, API rate limiting, syslog delivery, and SIEM correlation with representative applications. A useful proof of concept follows one user and one transaction across identity, endpoint, network, and fraud systems.

Is zero trust practical for a mid-sized financial institution?

It can be, provided the scope begins with sensitive access rather than every system. A mid-sized institution might start with administrators, payment operations, and third-party support accounts, using device certificates, FIDO2 credentials, and short-lived privileged sessions before expanding to broader employee populations.