Why FM's application testing service uses Aikido
FM's pentest offering uses Aikido, with FM reporting. The aim is repeatable testing tied to application changes, clear scope and follow-up on findings.
The cover image is an AI-generated editorial illustration. Screens and documents are illustrative concepts.
FM CyberSecurity’s application pentest offering uses Aikido, with FM producing its own reports. The reason to build around that platform is practical: testing should be repeatable when an application changes, and findings should lead to fixes that can be checked.
An annual assessment can provide useful depth. It cannot establish the security of a feature that did not exist when the assessment ran. A testing plan therefore needs both a defined scope and triggers for testing significant changes.
What the platform contributes
Aikido describes its pentest service as agent-based testing that explores an application’s attack surface and validates findings through exploitation. Its reports include reproduction details and remediation guidance, and the service supports retesting fixes.
Those capabilities make it possible to connect a finding to a concrete follow-up: which build was tested, what failed, who owns the correction and whether the corrected behaviour was retested.
Coverage still depends on the application, credentials, configuration and purchased scope. A test with one user role cannot establish that every boundary between customers and administrators works. A clean report means no findings were reported within that test; it does not establish that the application has no vulnerabilities.
Scope is part of the work
Before running a test, agree on target systems, user roles, permitted actions, test data and stop conditions. Include the APIs and access boundaries that matter to the business. A production target needs an explicit assessment of disruption and data risks.
Afterwards, prioritise findings by their effect on the application and the data it handles. Assign remediation owners and record any decision to defer a fix. Retest the relevant behaviour rather than closing an issue solely because a patch was deployed.
For certification work, connect that evidence to the management system.
Check the requirement before choosing the test
Automated application testing does not cover every kind of security assessment. Physical access, social engineering, specialist infrastructure testing and regulated threat-led exercises can require different methods and qualifications.
If a customer contract requires an independent manual assessment, agree how to satisfy it before purchasing a service. A product report does not override a contractual requirement, and no testing tool guarantees an auditor’s acceptance.
Compare proposals on scope, repeatability, access to findings and remediation support. The useful output is evidence about the application that helps its owner make a better security decision.
