Strategy & Governance

Managed Security

Cyber Defense

Governance, Risk & Compliance

Operations & People

Talk to us

Cyber Defense

OT and ICS security assessment without stopping the line.

An OT ICS security assessment in India has one hard constraint that IT testing does not: the thing you are testing is holding a physical process together. A scan that would be routine on a corporate subnet can crash a twenty-year-old PLC and take a plant down. So we start passively, and we earn the right to touch anything.

Operational technology was built for availability and safety on isolated networks, and then quietly connected: to the business network for reporting, to a vendor for remote maintenance, to a historian in the cloud. The controllers themselves cannot be patched on an IT cadence and were never designed to authenticate anything. The security has to come from architecture.

We map the estate by listening to the traffic, place every asset in the Purdue model, and test the boundaries between levels, which is where a compromise of the corporate network turns into a compromise of the process. The same work applies to IoT fleets, where the device is small, numerous and outside your building. Segmentation findings usually continue into network architecture review.

Why you need it

01 / 06

Why OT cannot be secured like IT.

01

Availability outranks confidentiality.

A patch window on a process line may be one weekend a year, or never. Controllers run for decades on firmware that cannot be updated without vendor sign-off and a validated restart. Compensating controls and segmentation do the work that patching does elsewhere.

02

The protocols have no security to misconfigure.

Modbus, DNP3, S7 and their peers were designed for trusted serial links. They authenticate nothing. Anyone who can reach the wire can read process values and, in most cases, write them. Reachability is therefore the entire control.

03

The air gap is almost always gone.

Remote vendor access, engineering laptops that move between networks, USB media, wireless sensors and a historian replicating to the corporate side. We regularly find a route between the business network and Level 2 that no one on either side knew existed.

04

The consequence is physical.

The impact of an OT incident is measured in production stoppage, equipment damage and safety, not in records disclosed. That changes which findings matter and it changes how carefully they may be tested.

Instrument

02 / 06

Where each asset belongs, and who it may talk to.

Select a Purdue level to see what typically lives there, which protocols we fingerprint passively, and which neighbours it should be allowed to reach.

What we deliver

03 / 06

What the assessment covers.

01

Passive asset discovery

A span or tap port and a listener. We build the inventory from the traffic itself (device, vendor, firmware version, protocol and conversation partners) without sending a single packet at a controller. For most clients this is the first accurate OT asset register they have had.

02

Protocol fingerprinting

Modbus, OPC-UA, EtherNet/IP, DNP3, S7, BACnet and IEC 60870-5-104 identified from observed traffic, with what each conversation is actually doing: reading a value, writing a setpoint, downloading logic to a controller.

03

Purdue-model segmentation review

Every asset placed at a level, then the boundaries tested. Level 3 to Level 2 controls, the demilitarised zone between enterprise and process, remote vendor access paths, jump hosts, and the flows that cross a boundary they should not.

04

Configuration and access review

Engineering workstations, HMIs and historians as the highest-value IT-like assets in the plant: patch state, shared and default credentials, removable media policy, application allow-listing, and who can download logic to a controller.

05

IoT device and firmware assessment

For connected device fleets: firmware extraction and analysis, hardcoded credentials and keys, update mechanism and signature verification, the provisioning and enrolment flow, wireless and radio interfaces, and the cloud API the fleet reports to.

06

Safe active testing, where permitted

Active work happens only on agreed targets, in an agreed window, and by preference against a test bench, a spare unit or a scheduled outage. Where a live controller is genuinely in scope, testing is stepwise with the operations team present and a stop word.

How we run it

04 / 06

Six steps, passive first.

  1. 01

    Initial consultation

    The process, the plant, the vendors, the constraints and the outage calendar. We also ask what has already gone wrong, because an OT team usually knows exactly which link is fragile.

    Week 0
  2. 02

    Scope definition and safety review

    Sites, cells, network segments and devices in scope, and, more importantly, what may never be touched. Safety instrumented systems are out of scope for active testing by default. Rules of engagement are signed by both the security and operations owners.

    Week 0
  3. 03

    Passive discovery

    Traffic capture at the agreed points, asset and protocol identification, and a conversation map. Nothing is transmitted toward a control device during this phase.

    Days 1-4
  4. 04

    Configuration and architecture review

    Firewall and switch configuration between levels, remote access design, engineering workstation and HMI hardening, backup and recovery for controller logic, and the documented architecture compared with what the traffic shows.

    Days 4-6
  5. 05

    Controlled active testing

    Only where authorised: boundary testing from the enterprise side, IT-like assets in the OT network, wireless and IoT devices, and bench testing of controller models on spare hardware. Operations staff are present throughout.

    Agreed window
  6. 06

    Reporting and recommendations

    Findings ranked by process consequence, not by CVSS, with remediation sequenced around your maintenance windows and separated into what is achievable now and what belongs in the next capital cycle.

    Days 8-10

Key benefits

05 / 06

What changes after.

You have an accurate asset register

Built from observed traffic rather than from a spreadsheet last updated at commissioning, including the devices, and the vendor connections, that nobody documented.

The boundaries are proved, not assumed

Each Purdue-level crossing is tested for what actually passes, so "it is segmented" becomes a set of rules you can point at, with the exceptions written down and owned.

Remediation fits the plant

Recommendations sequenced around outage windows, vendor support constraints and equipment that cannot be patched, so the plan survives contact with the operations team.

Tools we use

06 / 06

Named, and used on your engagement.

No “latest tech tools”. These are the ones your report will cite, alongside the manual work that a tool cannot do for you.

Passive discovery

  • Zeek
  • Wireshark with ICS dissectors
  • Malcolm
  • GRASSMARLIN

OT-aware assessment

  • Nmap ICS scripts (bench only)
  • PLCScan (bench only)
  • Metasploit ICS modules (bench only)

IoT and firmware

  • binwalk
  • Ghidra
  • firmware-mod-kit
  • HackRF
  • Ubertooth

Architecture and segmentation

  • Nipper
  • Firewall rule-base analysis
  • Purdue Enterprise Reference Architecture

Frameworks

  • IEC 62443
  • NIST SP 800-82
  • MITRE ATT&CK for ICS

Why Aphelion

Shared

Four things you can check.

01

The work is done by people with names.

Darshap Nayak, formerly of KPMG, holds a master’s degree in cybersecurity and more than seven years in security operations. Jaimin Somani brings fifteen-plus years of academic and hands-on VAPT. Hemang Desai is an ICT network specialist from Australia. You will meet them, not a logo.

Meet the team
02

Evidence, not adjectives.

Every finding arrives with the reproduction steps, the affected asset and the fix, ranked by what it actually reaches in your environment, not by a CVSS number copied from a scanner. You get the report and the raw output, not a summary of a summary.

See how we test
03

Two offices, one practice.

Ahmedabad and Sharjah, working the same methodology on the same tooling. Indian data-residency requirements and UAE delivery are both ordinary here, and the AphelioNYX AD Pen-Test module runs entirely inside your perimeter when regulation says it must.

The platform
04

What we will not do.

Invent a statistic to make a slide land. Publish your name as a client without written permission. Print an award badge nobody awarded. Founded in 2024. We say so, and we attribute experience to the people who have it.

Ask us anything

100+ organizations secured

Across the globe, and across eight industries. We name a client only with their written permission.

  • Finance & Banking
  • Healthcare
  • Retail & E-commerce
  • Technology
  • SaaS
  • Hospitality
  • Manufacturing
  • Pharmaceuticals

AphelioNYX is SOC 2, ISO and GDPR compliant; attestations are available on request under NDA. We would rather hand you the report than print a badge.

Questions

FAQ

What plant and security teams ask us.

Will the assessment disrupt production?
The default answer is that it cannot, because the default method is passive: we listen on a span or tap port and send nothing toward a controller. Active testing is opt-in per target, runs in an agreed window with operations present, and excludes safety instrumented systems entirely. Where a controller model must be tested actively, we prefer a spare unit on a bench.
Our OT network is air-gapped. Is this necessary?
It is worth finding out whether it still is. In practice the gap is bridged by remote vendor support, engineering laptops that also connect to the corporate network or the internet, USB media, wireless instrumentation, or a historian replicating outward. Passive discovery answers the question in a few days with no risk, and the answer is frequently not the expected one.
We cannot patch our PLCs. What can we actually do?
Almost everything that matters, because the control is reachability rather than patch level. Segment properly and enforce it at a firewall that understands the protocols; remove direct enterprise-to-process paths; broker vendor access through a monitored jump host with time-bound accounts; harden and patch the engineering workstations and HMIs, which are ordinary computers; and monitor the OT network for changes, since a logic download is a very loud event when anyone is listening.
How does this relate to IEC 62443?
IEC 62443 is the standard we structure findings against: zones and conduits, security levels and the asset-owner requirements in particular. The assessment gives you the current-state input that a 62443 programme needs: an asset inventory, an as-built architecture, and a gap list against the target security level for each zone. We are not a certification body and we do not claim to certify you.
Can you assess our IoT product as well as our plant?
Yes, and it is a different engagement shape. Product work covers firmware extraction and analysis, secure boot and update signing, provisioning and identity, radio interfaces, and the cloud API the fleet talks to, testing what a buyer of your device can do with it. Plant work covers the estate you operate. We scope them separately even where the same team owns both.

Forty-five minutes. Your environment, not a slide deck.

A personalised walkthrough and a free readiness assessment against the frameworks you are actually being asked for. Pick a time that suits you, or write to us. We reply within one business day.