MT4/MT5 admin access: the ISO 27001 evidence FX brokers always miss

If there is one control gap that appears consistently when reviewing the ISO 27001 readiness of FX brokers, it is admin access to the trading platform. MT4 and MT5 administrator credentials represent some of the most sensitive privileged access in a brokerage - the ability to alter trade records, adjust client balances, access real-time position data across the entire book, and modify system configuration. And yet, in the majority of readiness reviews, those credentials are managed with less rigour than a company's shared social media password.

This post is about the specific ISO 27001 evidence requirements around MT4/MT5 admin access, why brokers miss them, and what "good" looks like before an auditor asks the question.

Why trading platform admin is a privileged access control problem

ISO 27001:2022 Annex A.8.2 covers privileged access rights. The control requires that the allocation and use of privileged access rights be restricted, controlled, and reviewed. That is not a new concept - it was present in the 2013 version under A.9.2.3. What changes when you apply it to MT4/MT5 is that the platform has its own user management model that sits entirely outside Active Directory, Azure AD, or whatever identity provider a broker uses for standard IT access.

MT4 Manager and MT5 Manager are desktop applications (and, in the MT5 case, a web admin interface) with their own credential store. There is no SAML federation, no single sign-on, and - in most configurations - no native audit log that can be exported to a SIEM. That combination means the controls that work elsewhere in a broker's environment do not automatically extend to the trading platform.

The result is a set of access control facts that are invisible to the ISMS unless someone has deliberately mapped them.

The joiner/mover/leaver gap

The joiner/mover/leaver (JML) process is a fundamental identity lifecycle control. Under ISO 27001:2022 Annex A.5.18 (access rights) and A.8.2 (privileged access), the ISMS must demonstrate that access is provisioned on a need-to-know basis when someone joins, adjusted when their role changes, and revoked promptly when they leave.

In practice, most FX brokers have a JML process for their core IT environment. Leaver checklists exist, offboarding procedures cover email and VPN access, and there is some form of approval workflow for new starters. The problem is that MT4/MT5 admin accounts are almost never included in that process.

The failure pattern is representative of a type seen repeatedly: a dealing desk manager leaves, their MT4 Manager account is disabled on Active Directory, but the MT4 Manager credential itself - which authenticates independently against the trading server - remains active for months. If that person retained the password, they retain access to the trading environment.

This is not a hypothetical failure mode. It is a structural consequence of treating the trading platform as an operational tool rather than an information asset with privileged access controls.

Approval records: who authorised this account?

ISO 27001:2022 A.5.18 requires that access rights be allocated based on documented authorisation. For most IT systems, this means a ticket, an approval email, or a workflow in a provisioning system. For MT4/MT5 admin access, the question is: where is the record showing that each active admin account was reviewed and approved by someone accountable for that decision?

In readiness reviews, the answer is usually one of the following:

• "The previous IT manager set those up, we are not sure when"
• "Our MT4 provider set them up during implementation"
• "We do not have a record, but only the dealing desk uses them"

None of those answers satisfy the control requirement. The auditor needs to see, for each privileged account on the trading platform, an identifiable owner, a documented business justification, and an approval from someone with authority to grant that access.

The fix is straightforward: an access register for MT4/MT5 admin accounts, maintained as a live document, with named owners, approval records (even a retrospective audit of current accounts is acceptable as a starting point), and a review date.

Periodic access review: the control that rarely happens

Annex A.8.2 requires periodic review of privileged access rights. For standard IT systems, most brokers carry out some form of annual access review, often prompted by their internal audit schedule or a supplier's security questionnaire.

For MT4/MT5, periodic review almost never happens. There is no automated report. Pulling a list of active Manager-level accounts requires access to the MT4 Administration interface or a query against the trading server configuration, and that task belongs to whoever manages the platform day-to-day - typically the dealing desk or a technical operations function that does not see itself as part of the information security programme.

What the ISO 27001 auditor needs to see is evidence that a review has been completed - a dated record showing who reviewed the list of active admin accounts, what accounts were confirmed as still required, and whether any were removed as a result. The frequency should match what the broker has documented in their access management policy: typically quarterly or semi-annual for privileged accounts.

Shared PSP credentials: a related but distinct problem

MT4/MT5 admin access is the most visible privileged access gap for FX brokers, but it sits alongside a similar issue: shared credentials for PSP APIs and back-office payment tools.

A broker connecting to a card processor, an e-wallet, or a crypto payment rail will typically receive API keys or portal login credentials during onboarding. Those credentials are then distributed to whoever needs them - finance team, settlement team, technical operations - often via email or a shared password in a team chat. There is no individual accountability, no record of who has access, and no process for rotating credentials when a team member leaves.

Under ISO 27001:2022 A.5.17 (authentication information), shared passwords are a control weakness that requires compensating measures at minimum. For PSP credentials, the minimum acceptable position is:

• A named credential owner for each PSP integration
• Evidence that credentials are stored in an appropriate secret management tool or password manager with individual accountability
• A rotation history showing when credentials were last changed
• A clear process for credential rotation when access changes

If the same API key has been in use for three years and has been distributed to eight people across two teams, that is a finding that needs to be addressed before certification, not flagged by the auditor.

What "good" evidence looks like

For an FX broker approaching ISO 27001 certification, the evidence set for trading platform and PSP access should include:

Access register - a live document listing all MT4/MT5 Manager accounts and PSP credentials, with named owners, access levels, business justification, approval records, and last review date.

JML integration - written evidence that MT4/MT5 admin accounts and PSP credentials are included in the leaver checklist, with a completed example showing the account was disabled or credential rotated as part of a recent offboarding.

Periodic review records - dated minutes or sign-off documents showing that privileged access was formally reviewed, by whom, and what actions were taken. At least one completed review cycle before the certification audit.

Approval workflow - even a simple approval email trail is sufficient if it demonstrates that access was requested by an identified user, reviewed by a named approver, and granted with a business justification. The auditor is looking for accountability, not a sophisticated workflow tool.

Credential rotation evidence - for PSP API keys, a log or record showing when credentials were last rotated. The rotation date should be consistent with what the broker's privileged access policy says.

The audit conversation you want to avoid

An ISO 27001 Stage 2 auditor asking "can you show me the access review records for your MT4 Manager accounts?" should produce a folder, not a conversation about who manages that system and whether a record exists. The auditor is not interested in the operational answer. They are checking whether the ISMS extends to all significant information assets, and a trading platform processing millions of dollars in daily volume is unambiguously significant.

The goal of a readiness review is to surface that question - and the missing evidence - before the certification audit, when there is still time to build the access register, complete the first review cycle, and update the JML process.

Where Kellwick fits

Kellwick's readiness work with FX brokers includes a targeted review of trading platform access controls - MT4/MT5 admin accounts, PSP credentials, and IB portal access - against the ISO 27001:2022 Annex A requirements. If you want to know exactly what an auditor will ask and whether your evidence holds up, see how the FX broker readiness review works.