CERT-In Empanelled — Mandatory credential for regulated payment audits

ATM and POS Security Audit: Protecting Every Payment Channel from Terminal to Switch

Specialised payment-channel security assessment covering ATMs, POS terminals, CDMs, kiosks, microATMs, NFC tap-to-pay, payment middleware, and switch integration — anchored in the 24 baseline cybersecurity controls RBI requires a bank to impose on its third-party ATM Switch Application Service Provider by contract (para 138 of the RBI Directions, 2026), EMV standards, and PCI DSS v4.0.1.

Request a Scoping Call Our Methodology

ATM + POS

Audit Coverage

PCI-Aligned

Methodology

6,700+

Assessments

Since 2008

CERT-In Empanelled

Security Brigade delivers ATM and POS security audits that go far beyond generic vulnerability assessments. We test the complete payment chain — physical terminals, transaction logic, cardholder data flows, network segmentation, key management, and regulatory alignment — so your payment infrastructure is secure, compliant, and audit-ready.

Trusted by India's leading enterprises

Who the obligation lands on

The bank owes the control. The contract is how it reaches the switch provider

Most ATM and POS security conversations start in the wrong place, with the terminal. The Reserve Bank’s Directions start with the contract. Where a bank runs its ATM Switch ecosystem through a third party’s shared services, paragraph 136 makes the bank responsible for ensuring that a defined set of cybersecurity controls is implemented and maintained by that Application Service Provider, and those controls are not a separate annexure. They are cross-references back into the Directions themselves, covering prevention of unauthorised software, environmental controls, network management and security, and more. Paragraph 137 then says where they have to live: factored into the contract agreement signed with the Switch ASP, and applicable to that provider across its whole IT ecosystem (physical infrastructure, hardware, software, the reconciliation system, network interfaces, security solutions, the hardware security module, middleware, and the associated people, processes, systems, data and information) for ATM switch services and for any other type of payment system related service it provides to the bank. Paragraph 138 then requires the bank to mandate twenty-four baseline cybersecurity controls in that agreement. The practical consequence is that a bank can be entirely compliant inside its own perimeter and still be exposed, because the obligation it has not met is a clause missing from a contract signed three years ago with a provider nobody has assessed since. That is the gap this assessment is built to close, and it is why we test the provider’s environment and read the agreement, not only scan the estate.

What paragraph 138 asks for

Twenty-four baseline controls, and the four that engagements actually fail on

The full list belongs in the Directions, not on a marketing page. These are the ones we most often find unmet, with what an assessment looks for.

Control	What the paragraph requires	What we test
Default and trivial passwords	Default passwords on all network devices and systems of the provider are to be changed after installation, and the provider is not to use trivial or default passwords.	Credential testing across the switch estate, management interfaces and out-of-band access, not only the application tier.
Centralised authentication and authorisation	The provider is to implement centralised authentication and authorisation instead of per-device local accounts.	Whether privileged access is actually brokered centrally, and whether leavers were removed from every path, not the directory alone.
Source code review for critical applications	In respect of critical business applications, the provider is to conduct source code review.	Evidence that review happened on the version in production, and that findings were closed and not merely logged.
A Cyber Security Operations Centre	The provider is to set up a Cyber Security Operations Centre.	Detection efficacy against the scenarios that matter on a switch: not whether a SOC exists, but whether it sees the relevant events.
Relevant payment card standards	The provider is to comply with the relevant standards, including Payment Card Industry standards.	Scope and currency of the provider’s own attestation, and whether its scope covers the services it delivers to you.

Default and trivial passwords

What the paragraph requires: Default passwords on all network devices and systems of the provider are to be changed after installation, and the provider is not to use trivial or default passwords.
What we test: Credential testing across the switch estate, management interfaces and out-of-band access, not only the application tier.

Centralised authentication and authorisation

What the paragraph requires: The provider is to implement centralised authentication and authorisation instead of per-device local accounts.
What we test: Whether privileged access is actually brokered centrally, and whether leavers were removed from every path, not the directory alone.

Source code review for critical applications

What the paragraph requires: In respect of critical business applications, the provider is to conduct source code review.
What we test: Evidence that review happened on the version in production, and that findings were closed and not merely logged.

A Cyber Security Operations Centre

What the paragraph requires: The provider is to set up a Cyber Security Operations Centre.
What we test: Detection efficacy against the scenarios that matter on a switch: not whether a SOC exists, but whether it sees the relevant events.

Relevant payment card standards

What the paragraph requires: The provider is to comply with the relevant standards, including Payment Card Industry standards.
What we test: Scope and currency of the provider’s own attestation, and whether its scope covers the services it delivers to you.

Beyond the switch

The channel is wider than the ATM, and the weak points move

Terminal estate

ATMs, CDMs, kiosks and microATMs

Physical and logical attack paths on the terminal itself: unauthorised software execution, boot and BIOS protection, hard-disk encryption, USB and peripheral control, remote management interfaces, and the environmental controls the Directions name.
Acceptance

POS and NFC tap-to-pay

Terminal configuration, key management, firmware currency, and the acquiring path behind the terminal. Card-present acceptance concentrates risk in key handling and in the estate’s update discipline, not in the transaction itself.
Integration

Payment middleware and switch interfaces

Message handling between terminal, middleware and switch, including reconciliation. This is where logic flaws live, and where an assessment that tested the endpoints separately finds nothing.
The provider

The ASP environment itself

The provider’s IT ecosystem as paragraph 137 describes it, including its hardware security module, network interfaces and the people and processes around them. Assessed against the twenty-four controls your contract is required to mandate.
The paperwork

The contract that carries all of it

We read the agreement alongside the assessment, because the obligation at paragraphs 136 to 138 is discharged contractually. A control the provider operates but the contract never required is a control you cannot enforce.

What you receive

Written for the three people who will read it

For compliance

A control-by-control position against paragraph 138

Each of the twenty-four baseline controls with the evidence found, the gap where there is one, and whether the contract currently mandates it. The contractual column is the one that tends to surprise.

For engineering

Technical findings with reproduction steps

Terminal, middleware, switch-interface and provider-environment findings with proof, severity and the fix, tracked to verified closure in Lemon, not to a ticket marked done.

For procurement

A remediation position for the provider conversation

Where the gap sits with the service provider and not with you, the finding is written so it can be put to them directly, which is the form it needs to take if a contract is going to change.

Reused

Testing evidence that answers more than one obligation

The same assessment work feeds the bank’s wider cybersecurity position under the Directions, so this is not a standalone exercise producing a standalone report.

Methodology

How a compliance engagement runs

Every engagement follows this process through Lemon, our proprietary audit management platform.

Security Brigade's ATM and POS audit methodology is built specifically for payment environments. Every technique is designed to validate security controls without disrupting live transaction processing. The methodology covers physical terminals, application logic, transaction flows, network architecture, key management, and regulatory alignment in a single coordinated engagement.

Discovery

Scoping and Asset Inventory

We document the complete payment terminal estate — ATMs, POS devices, CDMs, kiosks, microATMs, NFC endpoints, middleware, and switch connectivity. Terminal sample selection follows a risk-based approach covering device types, locations, and transaction volumes.

Cardholder Data Flow Mapping

We trace cardholder data from the point of interaction through middleware, switch, acquirer, issuer, processor, and settlement. This includes PAN, BIN, track data, PIN block, EMV data, tokens, logs, receipts, and storage at every hop.

Terminal Hardening and Physical Security Review

We assess OS hardening, kiosk mode enforcement, USB and peripheral restrictions, patching, local user accounts, admin access, remote management, application whitelisting, logging, and physical anti-tamper controls per RBI and PCI requirements.

Testing

Network Segmentation and Architecture Review

We validate segmentation of ATM and POS networks from branch and store networks, management VLANs, payment switch connectivity, vendor support paths, and internet-facing exposure. Firewall rules are reviewed against intended policy.

Payment Application and Transaction Logic Testing

We test POS and payment application business logic including transaction manipulation, refund and void flow abuse, offline transaction handling, tamper detection, authorisation bypass, and failure-state behaviour using both manual testing and B-52 engine validation.

Delivery

Key Management and HSM Review

We review key ceremony procedures, key injection, PIN translation, PIN block handling, TR-31 and TR-34 compliance where applicable, dual control, split knowledge, key rotation schedules, and HSM configuration and access controls.

Switch and Middleware Security Assessment

Where in scope, we assess ATM switch security, payment middleware integration, admin interfaces, API endpoints, merchant portals, and terminal management systems for configuration, access control, and vulnerability exposure.

Regulatory and PCI Mapping, Reporting, and Closure

Findings are mapped to PCI DSS v4.0.1, EMV standards, and RBI ATM security guidance. The final report includes proof-of-concept evidence, risk ratings, remediation roadmap, and revalidation after fixes.

See a sample evidence pack →

"We have SAP, SCADA, 200+ web apps, and factories running legacy systems. Most security firms understand IT or OT — not both. Security Brigade tested our corporate network, our plant floor, our SAP interfaces, and our cloud migration path in one engagement with one methodology. The OT findings alone justified the engagement, but the real value was having everything in a single risk register."

VP Security, Manufacturing Conglomerate

Vice President — Information Security

The audit gives you a snapshot. ShadowMap gives you the always-on view.

An annual audit proves your posture at a single point in time. Between audits, attack surfaces drift, credentials leak, sub-domains get added, vendors get breached. ShadowMap watches the boundary continuously so the next audit isn't a surprise.

Threat Intelligence

1,000+ threat actor profiles, CVE tracking against your stack, IOC monitoring, and geographic threat analysis.

Know which threats are coming for you specifically.

Explore on ShadowMap

Brand Protection

Detects phishing domains, fake mobile apps, social media impersonation, and domain squatting — with orchestrated takedowns.

Stop impersonation before customers fall for it.

Explore on ShadowMap

See the full ShadowMap platform 30-day POC available · Platform Only · Service Only · Hybrid

FAQ

ATM and POS assessments, answered

Scope, obligation and who carries it. Talk to our team about your channel estate.

Where does the ATM switch obligation actually sit?+

With the bank, discharged through the contract. Where a bank manages its ATM Switch ecosystem through a third party’s shared services, paragraph 136 of the Directions makes it responsible for ensuring defined cybersecurity controls are implemented and maintained by that Application Service Provider, paragraph 137 requires those controls to be factored into the contract agreement, and paragraph 138 requires the bank to mandate twenty-four baseline cybersecurity controls in it. So a gap is as likely to be a missing contractual clause as a missing technical control.

How far does the provider assessment reach?+

Paragraph 137 describes it: the provider’s IT ecosystem (physical infrastructure, hardware, software, reconciliation system, network interfaces, security solutions, hardware security module, middleware, and the associated people, processes, systems, data and information) providing ATM switch services and any other type of payment system related service to the bank. That last clause matters, because it takes the scope beyond the switch to everything else the same provider runs for you.

Does this cover POS and tap-to-pay as well as ATMs?+

Yes. The assessment covers the acceptance channel end to end: ATMs, cash deposit machines, kiosks, microATMs, POS terminals and NFC tap-to-pay, plus the middleware and switch interfaces behind them. The reason to scope them together is that the interesting failures are at the joins: message handling and reconciliation between terminal, middleware and switch, which an assessment that tested each component separately will not find.

How does this relate to PCI DSS?+

They overlap and they are not the same exercise. Paragraph 138 requires the provider to comply with relevant standards including Payment Card Industry standards, so a provider’s PCI position is evidence for one of the twenty-four controls, but only to the extent its scope covers the services delivered to you, which is checkable and should be checked. Where card data is in your own environment, the PCI work is its own programme and we scope the two together so the testing evidence is produced once.

Who conducts the assessment?+

A CERT-In empanelled team. Empanelment is the precondition Indian regulators apply to who may perform an assessment of this kind, it attaches to the auditing firm for a defined period and not to a report, and Security Brigade has held it continuously since 2008.

Secure Your Payment Terminals Before Your Next Audit Deadline

Talk to our payment security specialists about your ATM, POS, or payment terminal audit requirements.

Request a Scoping Call

Typically responds within 1 business day · No commitment required