Operations & People
Network architecture review services are worth buying for one finding you can rely on getting: the network as documented and the network as running are not the same, and the difference is where an intrusion travels. Every estate accumulates a temporary rule from four years ago that nobody dares delete.
We review the design and then test it. Firewall and routing configuration analysed rule by rule, segmentation verified by attempting to cross it, remote access and management paths mapped, and the flows that actually exist between zones compared against the ones the architecture claims. The output is what passes, not what the policy says should.
The review also looks forward. Where the estate is being modernised, this is the point to design segmentation, Zero Trust access and hybrid cloud connectivity deliberately rather than accreting it. Where the environment includes industrial systems, continue into OT and IoT security; where identity is the real boundary, identity and access management.
Why you need it
01 / 06Once an attacker has a foothold, everything that follows is a question of reachability. A flat network turns one compromised laptop into an estate-wide event; a segmented one turns it into a contained incident. No detection tool substitutes for this.
Rules are added for a project and never removed, "any-any" appears as a temporary fix and becomes permanent, and objects outlive the servers they described. After a few years the rule base permits considerably more than anyone intends, and nobody can safely tell which rules are load-bearing.
Switch, firewall, hypervisor and out-of-band management interfaces reachable from the user network are the shortest route from an ordinary workstation to total control of the infrastructure, and they are rarely on anyone's list.
A VPN to one cloud, a peering link to another, a partner connection, a site-to-site tunnel for an acquisition. Each was reasonable; together they frequently create paths between environments that no one has ever drawn on a single diagram.
Instrument
02 / 06Toggle a single permitted path and watch the reachable set expand. This is the entire argument for segmentation, drawn rather than asserted.
What we deliver
03 / 06The architecture evaluated against defence in depth and least privilege: trust zones and the boundaries between them, ingress and egress control, exposed services, and whether a compromise in any one zone is contained by design or merely by luck.
Rule-base review for overly permissive, shadowed, redundant and unused rules; routing and VLAN configuration; network address translation; and the access control lists that were meant to enforce a boundary the firewall does not see.
Testing rather than reading. From a host in each zone, what can actually be reached in the others, including the management network, the backup network, the OT network and the guest network. The gap between the intended and actual matrix is the deliverable.
VPN configuration and split tunnelling, jump hosts and bastion design, vendor and third-party connections, out-of-band management, and every route by which an administrator, or someone holding their credentials, reaches the infrastructure.
Single points of failure, redundancy that has actually been tested, backup network isolation from the production domain, and whether the recovery plan depends on infrastructure that would itself be unavailable in the scenario it is written for.
Where the review supports a modernisation: a target architecture with segmentation model, access design and cloud connectivity, sequenced into changes that can be delivered without a maintenance window that never comes.
How we run it
04 / 06What the review is for (a security assessment, a modernisation, a compliance requirement or a post-incident review) and which sites, environments and connections are in scope. The objective changes what we look at hardest.
Week 1Diagrams, device configurations, rule bases, routing tables and documentation, plus interviews. We assume the documentation is incomplete, because it always is, and reconcile it against what the configurations actually say.
Weeks 1-2Segmentation gaps, permissive rules, exposed management interfaces, unmonitored paths and single points of failure, each rated by what it enables rather than by how it scores in isolation.
Weeks 2-3Firewalls, routers, switches, load balancers and VPN concentrators reviewed against hardening baselines, and the boundaries tested from inside each zone to establish what genuinely passes.
Weeks 3-4A prioritised remediation plan and, where in scope, a target architecture, sequenced so that the highest-value changes can be made without waiting for a redesign, with the rules identified as safely removable listed explicitly.
Week 5Key benefits
05 / 06Reconciled against live configuration and verified by testing, including the connections and rules that were not on the previous version.
Segmentation proved by attempting to cross it, so containment is a tested property of the network rather than an assumption in an incident response plan.
Shadowed, redundant and unused rules identified so they can be removed safely, which improves both security and the performance of the device enforcing them.
Tools we use
06 / 06No “latest tech tools”. These are the ones your report will cite, alongside the manual work that a tool cannot do for you.
Configuration analysis
Discovery and verification
Path and reachability
Cloud connectivity
Reference models
Included in this service
A review tells you what is wrong with what exists. Security architecture is the design work that decides what should exist, and it is considerably cheaper applied before a migration, a data-centre move or a major platform change than retrofitted afterwards.
We design the security layer of the environment: trust zones and the boundaries between them, identity and access as a first-class design element rather than an afterthought, data classification driving where controls sit, logging and monitoring designed in so that visibility is not a later project, and resilience patterns that survive the failure modes you actually face.
The deliverable is a reference architecture with design principles, patterns your teams can apply without asking, and a sequenced transition from the current state. Principles matter more than diagrams here: a team that knows why the boundary is where it is will make the right call on the next change, which no diagram can do.
Included in this service
Zero Trust is a design principle with an unfortunate amount of marketing attached. The principle is simple and correct: network location grants no trust, every request is verified on identity, device posture and context, and access is granted per resource and per session rather than per network segment.
The implementation is where organisations struggle, usually because it is attempted as an estate-wide programme. We deliver it incrementally against your highest-value systems: identity-aware access to critical applications first, then privileged administrative access, then progressive removal of the implicit trust the flat network grants, following NIST SP 800-207 rather than a vendor's definition.
Two honest caveats. Legacy applications that cannot authenticate per request need brokered access and compensating controls rather than a pretence of Zero Trust. And no product delivers it: your identity provider, device management and access proxy each contribute, and the design that joins them is the actual work.
Included in this service
Almost nobody is fully in one place. The estate is a data centre, one or two clouds, a set of SaaS platforms and the connections between them, and the security model of each was designed independently, by different people, at different times.
We design and review the join: connectivity and its trust implications, identity federated consistently so that one directory governs access everywhere, consistent policy and control standards across environments, and logging that lands in one place so an incident can be followed across a boundary rather than stopping at it.
The finding that recurs is a cloud environment connected to the corporate network by a VPN that grants far more reachability than intended, giving a compromised cloud workload a direct path into the data centre. Establishing what each connection actually permits, in both directions, is usually the highest-value hour of the review.
Why Aphelion
SharedDarshap 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 teamEvery 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 testAhmedabad 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 platformInvent 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 anythingAcross the globe, and across eight industries. We name a client only with their written permission.
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
FAQNext door
RelatedA 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.