MT5 Server Security: A Broker’s Guide to Access Control, VPS Risks and API Credentials

MT5 server security depends on who can access the platform, the infrastructure beneath it and the systems connected to it. For a Forex or CFD broker, the review must cover staff permissions, remote access and integration credentials.

In its 24 October 2026 notice, GMO Internet confirmed that its Onamae.com Desktop Cloud service had been accessed without authorisation and that customer information had been taken from the service. It also reported receiving customer complaints about unrecognised trades. The service provides a hosted Windows desktop environment that traders use to run tools such as MT4 and MT5. The notice does not establish that the MT5 core Trade Server was compromised.

The distinction matters: a compromised trading terminal, a stolen Manager credential and unauthorised server access require different investigations.

Map the Access Points Before Changing Controls

List the deployed Trade and Access Servers, Administrator access, Manager and Dealer permissions, hosting consoles, RDP connections, CRM integrations and Bridge or Gateway connections. Record an owner, purpose and revocation procedure for each account or connection.

Use this access risk matrix to guide the review:

Access surface	Main risk	Control to verify
Platform administration	Unauthorised configuration changes	Named accounts, limited permissions, approval records
Hosting console and RDP	Control of servers or infrastructure	Restricted access paths, supported MFA, access logs
Trader VPS	Exposure of saved trading credentials	Endpoint protection, trusted software, separate credentials
CRM and Manager API	Excessive permissions or leaked secrets	Dedicated service accounts, restricted scope, secret storage
LP and FIX connections	Misuse of connection credentials	Approved endpoints, credential ownership, session monitoring
External support	Privileged access remaining after work ends	Approved access window, activity records, prompt removal

Available controls depend on the component, deployed version and provider. Apply restrictions at the appropriate layer.

Separate Administrator, Manager and Dealer Permissions

Give each staff member an identifiable account and only the permissions needed for their work. Technical administration, dealing operations and customer support should have separate access profiles. A reporting task should not require permission to alter trading conditions or account balances.

Verify effective permissions rather than relying on account labels. Require approval for material changes to Groups, Symbols, routing and financial records, and retain the previous configuration where applicable.

Remove access when staff leave or responsibilities change. Give temporary permissions an expiry and an owner. Include these reviews in the broker’s MT5 maintenance checklist.

Secure Trading VPS and Remote Desktop Access

A trader’s VPS running MT5 and an Expert Advisor is a different environment from the broker’s production servers. If that VPS is compromised, saved trading credentials may be exposed without any compromise of the broker’s Trade Server. EA hosting services also differ; check the actual access model.

Keep administrative RDP access off unrestricted public networks. Use a controlled gateway or VPN, restrict permitted users and source networks, and review remote login records. Patch the access infrastructure as well as the destination server.

The CISA joint remote access guide provides guidance on controlling remote tools and privileges. Enable MFA at supported identity layers; Microsoft documents this for Remote Desktop Services. Do not assume the same capability exists for every MT5 account or interface.

Protect API and Integration Credentials

CRM, Manager API, LP and Bridge integrations may use different combinations of passwords, tokens, certificates and connection parameters. Inventory each secret, its owner and the systems that consume it. Avoid using a human administrator’s credentials for automated services.

Use a secrets manager with access controls and keep credentials out of source code, shared documents and support tickets. Restrict permissions and approved endpoints where supported. These practices are covered in the OWASP secrets management guidance.

Plan rotation around dependencies: identify every consumer, coordinate with the vendor, verify the replacement and retire the old credential. If compromise is suspected, prioritise containment over a routine maintenance schedule. An IP allowlist is an additional restriction, not a substitute for authentication.

Isolate Production and Limit Vendor Access

Separate production from testing, including credentials and administrative paths. Permit only necessary connections between platform components, integrations and management systems.

For vendor work, record who is connecting, what they may change and when access ends. Review the result before closing the request. Do not reuse production credentials on ordinary desktops or trader VPS environments. These boundaries should form part of the managed MT5 server hosting design.

Investigate Suspicious Access and Changes

Correlate available operating system, remote access, platform administration and integration logs. Record time zones and clock differences so events can be compared.

Investigate unexpected privileged logins, new accounts, unknown remote tools and unexplained changes to permissions, Groups or Symbols. Preserve logs outside the affected host where practical.

For execution or connection symptoms, use the MT5 server troubleshooting guide. Unusual trades require Dealing and Risk review; technical symptoms alone do not establish unauthorised trading.

Respond When Credentials May Be Compromised

Use an incident lead to coordinate technical containment and business decisions:

1. Establish scope. Identify affected accounts, systems, likely exposure periods and connected services.
2. Contain access and preserve evidence. Restrict affected connections promptly while retaining logs and relevant system evidence. Do not delay urgent containment for perfect evidence collection, or routinely reboot and erase logs.
3. Replace exposed credentials from a trusted device. Include related service credentials where the investigation indicates exposure. Avoid entering replacements into a suspect environment.
4. Check active sessions. Terminate or revoke them using supported controls and confirm the outcome with the responsible provider.
5. Escalate and validate recovery. Involve hosting and software vendors, Dealing, Risk and compliance as appropriate. Investigate persistence before returning systems to service.

GMO’s 23 October notice specifically warned that existing connections might persist after a password change, depending on the broker’s server behaviour. Password replacement and session control are separate checks; neither should be assumed to complete the other.

Reconcile Trading and Account Records

Successful login is only one recovery check. Review Orders, Deals, Positions, and balance and credit operations across the affected period. MetaQuotes explains the distinction between orders, deals and positions.

Compare account identifiers, timestamps, volumes and prices with available Bridge and LP execution records. Not every client trade has a matching external hedge, so reconcile against the broker’s actual execution model.

Preserve original records and document discrepancies before authorised corrections. Dealing and Risk should approve trading decisions. Infrastructure restoration and failover belong in the broader MT5 disaster recovery plan.

Define Responsibilities Across Providers

Assign responsibilities according to the contract and actual system control:

Party	Responsibility to document
Broker	Access approval, dealing decisions, client communication and applicable reporting obligations
Hosting or maintenance provider	Agreed infrastructure controls, maintenance, logs and technical response
MetaQuotes	Platform product support and fixes under its control, through applicable support arrangements
CRM or Bridge vendor	Its software, integration behaviour, credential controls and available logs
Liquidity provider	Its connection access, session handling and execution records

Confirm who can disable each credential, retrieve logs and authorise service restrictions. Record support hours and escalation contacts. Monitoring a server does not automatically include security investigation across every connected system.

MT5 Server Security Checklist for Brokers

Use this practical security review checklist during access reviews and after material changes. Record an owner and follow up date for each gap.

Check	Evidence to retain
No unnecessary shared or dormant privileged accounts	Current account and owner list
Permissions match staff duties	Approved access review
Remote access is restricted; supported MFA is enabled	Gateway and access configuration
Integration secrets have storage and rotation controls	Credential inventory without secret values
Vendor access has approval and an end time	Access and change records
Production and testing are separated	Reviewed network rules
Suspicious access and changes are traceable	Log coverage and alert review
Updates and backup recovery are checked	Compatibility and restoration records
Incident contacts and session controls are documented	Response procedure
Trading and account discrepancies can be investigated	Reconciliation procedure

This checklist is not a full security audit, penetration test or compliance certification.

How EBS FinTech Supports MT5 Security and Operations

EBS FinTech can assist with server access configuration, infrastructure monitoring, platform maintenance and technical investigation within an agreed scope. Connected system issues can be coordinated with the relevant vendors.

Review your hosting and access controls through our MT5 technical maintenance service. Agree on covered systems, support hours and responsibilities before work begins. Specialist security testing or SOC services require a separate, confirmed arrangement.