The platforms we have tested,
and how we test them

SecIQ has carried out security assessments of the platforms enterprises actually run on: Microsoft Azure and Entra ID, VMware vSphere 8, NetApp ONTAP and Keystone storage, ServiceNow, Microsoft 365, Azure Kubernetes Service, Java microservice and API estates, IPC Unigy trading communications, and Windows 11 and macOS corporate builds.

We name platforms rather than categories because the difference matters. Testing a hypervisor control plane is not the same skill as testing a REST API, and a consultancy that will not say which it has done is asking you to guess. Every engagement below is delivered under the practices set out in how we work and scoped through our penetration testing and security audit services.

Platform coverage at a glance

VMware penetration testing and vSphere 8 security assessment

A VMware vSphere 8 security assessment from SecIQ typically covers the whole control plane — vCenter Server, the ESXi hypervisor fleet, vSAN storage, virtual networking and the virtual machine estate — measured against the DISA STIGs, CIS Benchmarks and the vendor's own security configuration guide.

We have assessed multi-site hypervisor estates with vCenter Server Appliances joined in Enhanced Linked Mode under a shared single sign-on domain. That matters because a weakness in one site's vCenter is a weakness in every site that trusts the same SSO domain, and an assessment that stops at one appliance misses the point.

ESXi fleets are assessed cluster by cluster. DMZ, general workload, management, database and VDI clusters each carry a different hardening baseline, and we report against the baseline that applies to each rather than a single average.

A vSphere 8 assessment typically covers

• vCenter Server Appliance, including Enhanced Linked Mode and the SSO domain that binds it.
• ESXi hypervisor fleets across clusters of differing purpose, each against its own baseline.
• vSAN hyperconverged storage: data-at-rest encryption architecture, native key provider and key management model, storage policy security.
• Virtual networking: standard and distributed virtual switches, VLAN segmentation, traffic isolation, network I/O control, virtual switch security policies.
• Virtual machine estate posture: BIOS versus UEFI, Secure Boot, virtual TPM, hardware version currency and snapshot hygiene.

Interfaces commonly in scope

Findings are classified against the DISA STIGs for vCenter, ESXi and virtual machines with CAT I, II and III severity, cross-referenced to CIS Benchmarks and mapped to MITRE ATT&CK, including the ESXi platform matrix. Where one cluster or site is well hardened we say so and name it as the internal reference baseline to replicate elsewhere.

NetApp storage penetration testing and ONTAP security assessment

A NetApp ONTAP security assessment from SecIQ typically examines the cluster administration model, the storage virtual machine architecture, the management and telemetry plane and the NFS, SMB and iSCSI data protocols, and then validates that the storage layer's data-protection controls actually trigger when they should.

Storage is where the data is, and it is routinely excluded from penetration testing because nobody wants to break it. We have assessed ONTAP clusters on all-flash arrays across geographically separate data centres without destructive action, using the non-destructive practices applied to every SecIQ engagement.

An ONTAP assessment typically covers

• Storage Virtual Machine architecture — admin, system, node and data SVMs — together with the cluster administration model.
• The ONTAP role and permission framework, including custom roles and the privilege they accumulate over time.
• Management and telemetry plane: Active IQ Unified Manager, System Manager, the Keystone Collector appliance, AutoSupport and its embedded database tier.
• Data protocols: NFS export policies, CIFS/SMB shares and ACLs, iSCSI targets and CHAP configuration.
• Data-protection controls: anti-virus scanning integration, Autonomous Ransomware Protection, SnapLock immutable (WORM) storage, Multi-Admin Verification, FPolicy, audit logging and SIEM forwarding.

Validating ransomware protection, not just configuring it

ONTAP assessments typically include controlled, benign ransomware and malware simulation to confirm that Autonomous Ransomware Protection, anti-virus integration and FPolicy respond as configured. The simulation is coordinated with your security operations team in advance, with tooling, test files and source ranges disclosed, so the exercise is distinguishable from a real event and measures detection rather than causing an incident.

Keystone storage-as-a-service estates add a provider-managed telemetry path. We assess the Keystone Collector and its AutoSupport channel as part of the attack surface, because a monitoring appliance with cluster credentials is a target whether or not it belongs to you.

ServiceNow security assessment and MID Server penetration testing

A ServiceNow security assessment from SecIQ typically tests the tenant's web UI and Service Portal, REST and SOAP APIs, IntegrationHub flows, the ACL and role model and SSO configuration, and — where they are deployed — the on-premises MID Servers that give the platform reach into your network.

We have assessed ServiceNow tenants on current releases, in authorised non-production instances and in line with the vendor's testing policy, with the major application suites in scope — ITSM, HRSD, ITOM with Discovery and CMDB, ITAM and portfolio management.

Tenant surfaces typically in scope

• Web UI and Service Portal, including the widgets and client scripts that render them.
• REST and SOAP APIs, both platform-native and application-specific.
• IntegrationHub flows and the credentials they hold.
• The ACL, role and RBAC model — who can read, write and delete which records.
• Single sign-on via SAML and OIDC, and session handling once authenticated.

MID Server penetration testing

MID Servers are Java applications on Windows or Linux hosts inside your network, and they run Discovery probes under a service account that usually has broad read access to everything they discover. We test the application, the probes, the service-account model and the hardening of the host operating system, because a compromised MID Server is a foothold with an inventory attached.

Connected identity and data sources are typically in scope too: AD and LDAP integration, CMDB population connectors, cloud discovery connectors, and orchestration and automation integrations. Each is a credential the platform holds on your behalf, and each is assessed for what it could reach if misused.

Microsoft 365 SCuBA assessment

A Microsoft 365 SCuBA assessment measures a tenant against the CISA Secure Configuration Baseline, producing a per-policy result — pass, fail, or flagged for manual review — against each SCuBA baseline policy ID across Entra ID, Exchange Online, SharePoint Online, OneDrive for Business, Teams, Defender and Power Platform.

SCuBA gives a tenant assessment something most Microsoft 365 reviews lack: a published, control-by-control baseline that a result can be traced back to. Our assessments are tool-assisted and expert-validated, so every failing control has been confirmed by a consultant rather than read off a scan, and every passing control has been checked for the configuration drift a tool cannot see.

Typically in scope

• Entra ID tenant: Conditional Access, MFA strength and phishing resistance, Identity Protection, Privileged Identity Management, service principals, app registrations and OAuth consent.
• Workloads: Exchange Online, SharePoint Online, OneDrive for Business, Teams, Defender for Office 365, Defender for Endpoint and Power Platform.
• Email authentication posture: SPF, DKIM and DMARC, together with Defender preset and impersonation policies.
• Hybrid identity: Entra Connect, AD FS and on-premises connectors.

How access is handled

Testing is performed non-interactively through a certificate-authenticated service principal holding least-privilege Graph, Exchange and SharePoint permissions. No consultant needs a user account in your tenant, no password is shared, and the service principal can be removed the moment testing ends. The output is a per-control PASS/FAIL register by SCuBA baseline ID, which drops directly into compliance and remediation tracking.

Azure cloud security assessment

An Azure cloud security assessment from SecIQ typically covers identity, container, API gateway, data, secrets, network and monitoring layers across the subscriptions agreed at scoping — commonly development, production and hub, measured against the CIS Microsoft Azure Foundations Benchmark with NIST SP 800-53 control mapping.

We have assessed Azure estates running to tens of thousands of resources, spanning development, production and hub or shared-services subscriptions. Estates at that size are not reviewed by hand; they are enumerated programmatically and then the material findings are validated by a consultant, with the sampling approach stated openly in the report.

Layers assessed

• Identity: Microsoft Entra ID — OAuth 2.0 and OIDC flows, Conditional Access, MFA enforcement, directory and application roles, Privileged Identity Management, service principals and managed identities.
• Containers: Azure Kubernetes Service, detailed in the next section.
• API layer: Azure API Management and Application Gateway — gateway policy enforcement, JWT validation policies, quotas and rate limiting, IP restriction, request and response schema validation.
• Data and secrets: managed SQL, Cosmos DB, storage accounts, Key Vault, centralised app configuration, search and indexing clusters.
• Network and monitoring: NSGs, VNets, private endpoints, WAF, DDoS posture, cloud-native monitoring, posture management and policy compliance.

Findings are reported against CIS Microsoft Azure Foundations Benchmark recommendations and mapped to NIST SP 800-53 controls, so the same evidence serves both the engineering team fixing the issue and the governance team reporting on it. Systemic issues — one misconfiguration repeated across hundreds of resources — are reported once, as a pattern, with one centralised fix.

Azure Kubernetes Service (AKS) security assessment

An AKS security assessment typically examines cluster RBAC, pod security, network policy, service accounts, secrets handling and API-server exposure, both from outside the cluster and from the position of a workload already running inside it.

Kubernetes clusters accumulate permissions the way file shares accumulate access: incrementally, and rarely reviewed. We assess whether a compromised pod can reach the API server, what its service account can do when it gets there, whether secrets are mounted more widely than they are needed, and whether network policy actually constrains east-west traffic or merely exists.

• Cluster RBAC: roles, bindings and the reach of default service accounts.
• Pod security: privilege, host namespace access, capabilities and admission control.
• Network policy: ingress and egress constraints between namespaces and to the control plane.
• Secrets handling: mounting, Key Vault integration and exposure in environment variables and logs.
• API-server exposure: authorised IP ranges, private cluster configuration and authentication paths.

AKS assessments are delivered as part of a wider Azure cloud security assessment or as a standalone engagement, and are measured against the CIS Microsoft Azure Foundations Benchmark and the CIS Azure Kubernetes Service (AKS) Benchmark.

API penetration testing from OpenAPI specifications

API penetration testing from an OpenAPI specification uses the documented contract as the coverage baseline for the published endpoints and methods, then adds black-box discovery for the endpoints the specification omits.

We have assessed API estates of 70+ documented APIs comprising 1,300+ endpoints, and Java and Spring Boot microservice estates of 80+ independent services. At that scale, coverage has to be engineered rather than assumed, and the report states how much of the population was tested and how.

Access paths covered

• Internet-facing external surface.
• Internal surface reachable over site-to-site VPN behind an internal load balancer.
• Machine-to-machine flows using OAuth 2.0 client-credentials grants.

Authorisation assurance

RBAC and authorisation testing is carried out across multiple user roles, including tenant-boundary and role-boundary testing — can user A read tenant B, can a read-only role write, can a service credential reach a human-only function. Broken object- and function-level authorisation are the most common serious API findings, and they do not show up in a scanner.

Work is carried out against OWASP WSTG v4.2, OWASP ASVS 5.0, the OWASP Top 10 (2025), the OWASP API Security Top 10 (2023) with coverage of API1 through API10, and the SANS Top 25 weakness classes. Each finding cites the category it falls under, and tool names and versions are listed in an appendix so results are reproducible. See penetration testing for engagement structure.

Windows 11 and macOS endpoint build review

An endpoint build review typically assesses a corporate Windows 11 or macOS standard build both authenticated and unauthenticated, covering disk encryption, boot integrity, credential protection, application allow-listing, device management enrolment and egress controls against CIS Benchmarks, NIST hardening guidance and your own corporate baseline.

We have assessed Windows 11 Enterprise and macOS Apple Silicon standard builds as a user would receive them, and as an attacker would find them: with a valid account, without one, and with physical access to the device.

Management and identity stack

• MDM enrolment via Intune and Jamf, including Jamf Connect.
• Self-service elevation and the boundaries it enforces.
• Defender for Endpoint.
• Active Directory and Entra ID integration.

Hardening surface

• Disk encryption: BitLocker and FileVault, including recovery-key handling.
• Boot and platform integrity: Secure Boot and System Integrity Protection.
• Credential protection: Credential Guard, LSA protection, keychain and DPAPI credential stores.
• Host firewall, VPN client, and egress and proxy configuration.
• Application allow-listing via AppLocker and Gatekeeper.
• Removable media and DLP controls.

Active Directory attack-path assessment

A build is only as secure as the directory it joins. We assess credential exposure in directory attributes, Kerberoasting and AS-REP roasting exposure, DCSync-capable privilege discovery, stale account and privileged group hygiene, and GPO hardening drift, and report the resulting paths from a standard workstation to domain-level privilege as attack chains rather than isolated findings.

Detection efficacy and control validation

We assess whether endpoint detection and response actually fires on the techniques it was bought to catch. Where a technique needs to be exercised in a controlled way, we develop tooling specifically for the engagement, pre-notify your detection team, and report which techniques were detected, which were blocked and which passed silently. Tamper protection and attack-surface-reduction rule gaps are reported alongside, so the output is a prioritised list of detection improvements rather than a verdict on the product.

IPC Unigy and trading floor communications security testing

Trading floor communications security testing can span the IPC Unigy platform end to end — typically the cloud service with its administration portal and APIs, Windows, macOS and mobile soft clients, trader turrets and touch control panels, SIP telephony and session border controllers, and the recording appliances that make the estate a regulated record.

Trading communications estates combine a cloud control plane, desk hardware that is effectively IoT, and telephony infrastructure that predates both. We have assessed all three tiers together, because the interesting paths cross between them.

A Unigy assessment typically covers

• The cloud trading-communications platform, its administration portal and its APIs.
• Endpoints and hardware: Windows and macOS soft clients, mobile clients, trader turrets and touch control panels assessed as IoT-class devices, SIP phones and USB audio devices.
• On-premises infrastructure: session border controllers, mediators and recording appliances.
• Telephony and integration surface: SIP trunks, private circuits, call-recording export APIs and third-party integration APIs.

Client binary review

Soft-client and mobile binaries are reviewed for secure storage, hardcoded secrets, code signing, certificate pinning, memory protections and debug leakage. Turret hardware is tested on site where physical access is required — a turret is a networked computer on every trading desk, and it is assessed as one.

CSA CCM and CAIQ cloud assurance

SecIQ assesses cloud services against the Cloud Security Alliance Cloud Controls Matrix v4 — 197 control objectives across 17 domains — and supports CAIQ v4 questionnaire work for both cloud providers preparing responses and customers evaluating them.

Most practical cloud risk sits in the gap where the provider and the customer each assume the other holds a control. The first output of a CCM engagement is a shared-responsibility delineation that states, control by control, who owns what. Everything else follows from that.

Assess once, report against many

The Cloud Controls Matrix carries published equivalences to other frameworks, so a single evidenced assessment can be reported against several of them.

CAIQ v4 on both sides of the table

For a provider, we help prepare responses that are defensible and evidenced, so the questionnaire survives a customer's scrutiny. For a customer, we critically evaluate the responses received rather than accepting them at face value — a "Yes" with no evidence behind it is a finding, not an answer.

Continuous audit metrics

With modern release velocity, an annual point-in-time audit no longer gives meaningful ongoing assurance. We design continuous audit metrics that are owned by a named person, actionable, measured often enough to intervene, traceable to a control, and tamper-resistant. This is offered through compliance consulting as an advisory engagement.

Practices common to every platform assessment

Every SecIQ platform assessment is delivered under the same practices: scope is verified independently before any active testing, findings are proved or disproved before they are reported, attack chains are rated on cumulative business impact, anything actively exploitable is issued as an interim notice during testing, and a retest is written into the engagement rather than sold afterwards.

Before testing begins, a passive reconnaissance stage — passive DNS, certificate transparency logs and routing attribution — produces a signed-off target list, because asset inventories are routinely wrong and we do not test what we cannot show you own. No finding cites a published vulnerability identifier until the observed build has been confirmed against the vendor's fixed-build advisory; anything short of that is reported as a configuration observation, not a CVE.

How reports are delivered

Reports ship as a PDF together with a sortable spreadsheet or CSV of every finding, ready for direct import into your vulnerability management platform. Each finding carries its confirmation status — configuration gap, validated, confirmed exploited or retracted — and tool names and versions are listed in an appendix so results are reproducible. Controls that hold are documented alongside those that fail, and anything that could not be tested is disclosed with the reason, so you can manage the assets whose status remains unknown rather than assuming coverage. The full method is set out in how we work.

Ongoing validation of scanner output and re-scoring against your own vulnerability management platform is available through managed security services. Further reading on platform-specific testing is published in insights.

Scoping a platform assessment

Tell us which platforms are in scope and how they are reached, and we will come back with a scoping questionnaire and an access and connectivity addendum before day one. Contact SecIQ.