Vulnerability Remediation
Findings are easy to produce and expensive to leave open. Once the environment is understood, from a Threat Actor Perspective review, a penetration test, or a report someone else wrote, ArcTech implements the fixes and verifies they hold across cloud, identity, APIs, web, application code and network. Where a finding cannot be fixed, because a library has no patched release or a rebuild costs more than the risk warrants, the attacker's use of it is removed instead and the residual risk is written down. Work is prioritized by attack chain rather than severity label: low and medium findings that combine into a route to domain or tenant compromise are treated as more urgent than an isolated high that leads nowhere.
Request a quote · Typically 2–3 months · scope-dependent
- Establish what we are working withA review, a test report, or your own findings list, whatever exists. Anything unclear or unverified is confirmed before it is scheduled, because remediating a false positive costs the same as remediating a real one.
- Remediation plan and sequenceFindings are grouped by root cause rather than by report line, then sequenced by the attack chains they belong to. A CVSS score describes one issue in isolation; attackers combine issues. A read-only misconfiguration, a stale service account and an over-permissioned app registration can each be rated medium and together produce a path to Global Administrator, that chain is closed before an unrelated high-severity finding that leads nowhere. Each item carries an effort estimate so the plan can be cut to a budget.
- Agreed access and change controlWrite access scoped to exactly what is changing, working inside your change process rather than around it. Nothing is altered in production without the approval it normally requires.
- ImplementationThe work itself, across the stack: Conditional Access and PIM rebuilt, privileges reduced in Entra ID and Active Directory, authorization logic corrected in application code, API authentication and session handling repaired, network paths segmented, secrets moved into managed storage, infrastructure defined as code and pipelines hardened.
- Where a direct fix is not possibleSome findings cannot be closed by changing code. A vulnerable library may have no patched release, an upstream dependency may pin it, the component may be third-party or out of support, or the rebuild may cost more than the risk warrants. The work then shifts from repairing the flaw to removing the attacker's use of it: restricting the path that reaches the component, cutting the privileges it runs with, segmenting what it can talk to, adding detection where prevention is not available, or placing it behind a control that has to be defeated first. The finding is recorded as mitigated rather than fixed, with the residual risk and the reasoning written down so it can be revisited when the constraint changes.
- VerificationEach closed finding is re-tested, and the attack path it belonged to is confirmed no longer to complete. Closing a finding without confirming the path is closed is how the same issue reappears at the next test.
- HandoverDocumentation of what changed and why, the automation and tooling written along the way, and a working session with your team so the capability remains in-house. The tooling remains yours.
- Findings closed, not just documented
- Verification evidence for each one
- Anything not fixed recorded as mitigated, with the residual risk
- A record of what changed and why
- Automation and tooling you keep
- Handover session with your team
Questions people ask
How long does remediation usually take?
Two to three months is typical. The real drivers are the scale of the estate, the budget available and how much residual risk you are willing to carry, a programme can legitimately stop once the chains that reach something valuable are closed, leaving lower-consequence findings documented and accepted. Short engagements of a fortnight are viable when the scope is a specific set of findings; anything approaching six months usually means the underlying design is being rebuilt rather than patched.
How can you estimate this without knowing our codebase?
Not precisely, and anyone quoting a firm figure for a codebase they have not seen is guessing. What is agreed up front is scope and time rather than a number of closed findings. The plan orders the work by attack chain so the paths that reach something valuable close first, and the engagement delivers as much of that order as the agreed time allows. At the end you receive a written account of what was fixed, what was mitigated rather than fixed and why, and what was left along with an estimate now that the codebase is familiar. The remainder can then be scheduled, re-scoped, or accepted with the residual risk understood rather than discovered later.
How do you know the fix actually worked?
Because the same capability that finds an attack path can confirm it no longer completes. A supplier who only implements changes can tell you the change was made; that is a different claim from the route being closed, and the difference is where the same finding comes back at the next audit. Every closed finding here is re-tested and the chain it sat in is walked again, by someone who does that testing professionally rather than as a box to tick.
How do you decide what gets fixed first?
By attack chain, not by severity label. Severity scores rate each finding in isolation, which is not how a compromise happens, an intruder strings together whatever is available. Two or three findings rated low or medium will frequently combine into a complete path from an ordinary user account to domain or tenant compromise, while a high-severity finding on an isolated system with no onward access is genuinely less urgent. The plan closes the chains that reach something worth reaching, in order of what they reach.
Do we have to have bought a review or test from you first?
No. A report from another supplier is a perfectly good starting point, and so is an internal findings list. Anything unclear or unverified gets confirmed before it is scheduled, remediating a false positive costs as much as remediating a real one.
What does the stack cover?
Azure and cloud infrastructure, Entra ID and identity including Conditional Access and PIM, Active Directory and hybrid federation, APIs, web applications, application code, network design and segmentation, infrastructure as code in Bicep and Terraform, and CI/CD pipelines. Work outside that range is declined rather than attempted.
Isn't it a conflict of interest to fix what you found?
Only if the fee rose with the findings, and it does not: reviews and tests are scoped and estimated before any work begins, and the estimate does not move because the report runs longer. In practice a good deal of remediation work starts from someone else's report. A test was run two or three years ago, part of it was fixed, the rest was not, and both the environment and the code have moved since. There is nothing there for ArcTech to have inflated. The engagement then runs as a loop, fix and retest and fix again, until the findings in scope are either closed or consciously accepted. When that is done you are free to commission the final check from anyone you like, and where an auditor requires that verification to be independent of whoever implemented the fix, that is the right way to do it.
Do you work through consultancies and intermediaries?
Yes. A substantial share of ArcTech's work is delivered as a subcontractor to consultancies or through broker placements, alongside direct engagements.
What stays with us afterwards?
Documentation of what changed and why, every piece of automation written during the engagement, and a handover session. The tooling remains yours.