Custom RMM software development
Remote monitoring and management is software that allows an IT service provider or an in-house IT department to monitor and manage devices remotely. An agent on each workstation and server measures what is happening, reports anything abnormal and carries out work: installing updates, running scripts, restarting services, joining a session to resolve a fault. This makes an RMM both the most useful and the most sensitive system in an IT estate, as it holds far-reaching rights on every connected device. Appfront builds management software for organisations that a standard package doesn't meet.
What distinguishes an RMM from standalone monitoring
Monitoring measures and signals. A probe checks whether a server responds, whether a disk is filling up, or whether a service is still running, and sends an alert once a threshold is exceeded. Then it stops: someone reads the alert, logs in manually and fixes the problem. That works well enough for a handful of systems in the same location.
An RMM adds the ability to act on what it measures. The same agent that reports a full disk can also clean it up. The same agent that sees a missing security update can install it. The distinction lies not in the measurement data but in the permissions: an RMM may change the device, usually with the highest rights the operating system allows, without anyone sitting at that device. The tool thereby shifts from observing to intervening, and the risk profile changes with it.
The second distinction is scale. Standalone monitoring is set up per system. An RMM is set up around a collection: hundreds or thousands of devices, spread across clients, sites and departments, with policies that differ by group. Viewing a single device is then the exception. The normal way of working is an overview in which deviations rise to the surface, with an action you can apply to a whole group at once.
The third distinction is that an RMM itself produces work. An alert that goes nowhere is noise. An alert that becomes a ticket, is assigned to a technician and only closes once the measurement is back to normal, is management. That is why almost every management platform has an integration with a ticketing system, and why that integration largely determines whether the platform delivers anything.
It helps to also state what an RMM is not. It is not antivirus, nor endpoint detection and response: those tools look for malicious behaviour, whereas an RMM looks at the state of the device and at most reports whether the security software is running. It is not a backup solution, although it almost always monitors whether the backup has succeeded. Nor is it the same as mobile device management, which is mainly about configuration profiles and access to business data and usually works through the manufacturer's channels. In larger organisations these layers sit alongside one another, and the real question is who regards which measurement as the source of truth. Agreeing that in advance prevents two systems from contradicting each other about the same machine.
Are you in the right place? This page is about managing devices, not tracking people. If you are looking for software that records how employees spend their time, which applications they use or which websites they visit, you want employee monitoring software. That is a fundamentally different category, with its own legal framework and its own conversation with the works council. An RMM measures the state of a laptop; employee monitoring measures the behaviour of the person behind it. In the market these two are often confused, and it pays to decide at the start of a project which side you are on.
Measuring and being allowed to intervene
The agent does not only read, it also acts. That saves manual work and at the same time calls for a tight permissions model.
Set up from the collection
Policy per group, actions across a whole set of devices at once. Viewing a single device is the exception.
An alert becomes work
Without an integration to tickets, monitoring stays a dashboard. With one, it becomes a queue with follow-up.
The agent on the device
Anything an RMM can do, it does through the agent. This is a small programme that runs as a service on the workstation or server, collects measurement data and carries out instructions coming from the platform. It is the component where most of the engineering lives and where most design choices are made, because the agent operates beyond your reach: on a laptop sitting on a train, on a server behind a firewall you do not control, on a machine that only comes back online on Monday morning.
The first design decision is the direction of the connection. An agent that waits for the platform to make contact requires an open inbound port, and that is precisely what you do not want. Almost all management platforms therefore work the other way round: the agent calls out itself, keeps that connection open and picks up instructions over it. The advantage is that you do not need to open any port. The disadvantage is that the platform then has a permanently open channel to every device, which an attacker who gains control of the platform could use immediately.
The second point is what the agent does when it hears nothing. Networks drop, laptops close, connections are severed. An agent that only works while the platform is reachable loses measurements and leaves a gap in the history. An agent that keeps measuring locally, stores its observations on disk and sends them once connectivity returns, keeps the timeline intact. The same applies to instructions: a task scheduled during the outage should still be carried out afterwards, but not six times just because the instruction was delivered six times. That calls for instructions with their own identifier and an agent that keeps track of what it has already done.
The third point is how much the agent may decide for itself. A fully directed agent is predictable but slow: every action has to travel back and forth. An agent with local policy responds immediately, even without a connection, but you then need to be able to roll that policy out, version it and roll it back. In practice a hybrid works best: thresholds and remediation actions handled locally, anything with an impact on multiple devices managed centrally.
The fourth point is how the agent gets its identity. When rolling out, a freshly installed agent has to register with the platform and then remain recognisable as that specific device. If this is done with a single shared enrolment secret stored in an installation script, anyone who obtains that script can add a device to your environment or impersonate an existing one. A one-time enrolment that is tied to a short validity period and is then replaced by a unique key per device solves this. You must also be able to revoke that key, because a stolen laptop should no longer be able to fetch commands.
A separate component is remote viewing and takeover. Technically, this is separate from automation: it is an interactive session in which a technician sees the screen and takes control. Precisely because it is the most visible feature, it deserves the strictest rules. Who may start a session, whether the user can see that someone is watching, whether they must give their consent, and a record of who logged in, when, and on which device should all be captured. A server with no logged-in user is different from an employee's laptop, and that difference belongs in the permissions model rather than in a working agreement.
In practice, most of the work on the agent is not a clever trick but persistence. It must run on multiple operating systems and behave as a well-mannered service on each of them. It must not use so much processing power or disk space that users notice it. It must be able to update itself, since manually visiting a thousand devices is not an option, and that self-update must be able to roll back to the previous version if the new one fails to start. It must stop cleanly when the device shuts down and come back up when it boots. And finally, it must be removable from a device without leaving remnants behind. That last point sounds trivial and is not: a management agent that you cannot properly get rid of is a problem for a security team rather than a tool.
Moreover, not every device accepts a standard agent. Point-of-sale systems, measurement setups, industrial controls and equipment the vendor has locked down often do not allow arbitrary software. For those devices you fall back on what they offer themselves: a network protocol, a log file, a proprietary management interface, or sometimes little more than a status light. A management platform that takes this into account has, alongside the agent, a second route by which a device can report its state. This is one of the few situations in which a standard package structurally falls short, and therefore also one of the places where the demand for custom development comes from.
The data the agent sends deserves an explicit choice. Technically, it can see almost everything that happens on the device. That does not mean it should forward it. A sensible boundary keeps to state data: hardware, operating system, installed software with version numbers, running services, disk space, memory, network, backup status, antivirus and disk encryption status, and the results of executed tasks. File contents, screenshots taken without consent and keystrokes do not belong in that set. Settling that boundary in advance saves a difficult conversation later, and also demonstrably shows that the system is not a staff monitoring system.
What an RMM platform must be able to do
These components are interconnected. Status monitoring without follow-up produces a dashboard nobody opens, automation without a permissions model creates a risk, and an inaccurate inventory renders all reporting built on top of it worthless. The order in which you build them is therefore rarely up for grabs: inventory first, then monitoring, then actions.
An inventory that keeps itself up to date
Hardware, operating system, installed software and version numbers per device, measured automatically rather than retyped annually.
Status monitoring with thresholds
Measurements with a norm per group, so that deviant behaviour stands out and normal fluctuations do not trigger alerts.
Scripts and automation
Repeatable work recorded as a task, with version control, a test group and a clear view of where the task does and does not run.
Patch management with evidence
Not just rolling out updates, but also measuring whether the update is actually active and recording why a device is falling behind.
Alerts that become tickets
Rules for merging, suppressing and closing automatically, so that the queue contains work rather than background noise.
Permissions per technician and client
Who may view, who may act, and on which device group, with an audit trail that can be followed afterwards.
Patch management is where things go wrong
Ask any managed service provider which part of the RMM delivers the most value and the answer is patch management. Ask which part most often fails to do what it promises and the answer is the same. That is no coincidence. Patch management is the only area where the platform makes a promise about the reality outside itself, and that promise is hard to keep.
It starts with the difference between rolling out and being active. An update that has been downloaded is not installed. An update that has been installed is not always active: many patches only take effect after a restart, and that restart is exactly when users tend to postpone it. A platform that records status at the moment of rollout shows green ticks for devices that have been waiting weeks for a restart. Anyone steering by that report believes the matter is in hand.
On top of that, status can regress. An image that is restored, a user who installs an older version, an application that updates itself and in doing so replaces a component: each is a way in which a device that was correct last week is no longer correct this week. Patch status is therefore not an event but a measurement you must keep repeating, with a timestamp attached, so that it is visible how old the picture is.
The second problem is coverage. The operating system is the easy part: there is a vendor, a channel and a fixed rhythm. Microsoft has marked Windows Server Update Services as no longer under active development, although existing capabilities and content remain available to current deployments. That makes the question of where you anchor patching for workstations and servers more pressing than it has been for years.
More important still is everything beyond the operating system. Browsers, PDF readers, archiving tools, runtimes, database clients, development tooling: each with its own vendor, its own installation method and its own rhythm. This is the part where most vulnerabilities are in practice actually exploited, and at the same time the part that is hardest to automate, because there is no common channel. An RMM that only updates the operating system covers the smallest part of the risk.
Why delaying is sometimes the right choice
There is another reason patch management is hard going: installing everything immediately is not always wise. An update can break an application that a department depends on, and the party who notices is not the one who rolled the update out. Managed service providers therefore work in rings: a small group of devices receives the update first, then a larger group, then the rest. This only works if the platform knows those rings, can defer per ring, and keeps the deferral visible rather than hiding it.
Reporting is the final piece and is usually underestimated. Clients and auditors don't ask whether you patch, but whether you can demonstrate that you patch. That requires a report that can be reproduced for a point in the past: what the landscape looked like last month, which devices were lagging behind, and why. An overview showing only the current state is useless for that question. Keeping history is a choice you make in advance, because reconstructing it afterwards is not possible.
What makes this manageable is that every exception is given a reason and an expiry date. A device may lag behind because a vendor doesn't yet support the new version, but then there should be a note attached and a point at which someone revisits it. Without those two elements, the list of exceptions quietly grows until it covers most of the landscape, and that is precisely the point at which the report becomes useless. If you see this pattern in the maintenance of physical installations too, then custom maintenance software development is the relevant entry point.
- Re-measure status, don't infer it from the rollout
- Treat a restart as a separate state with its own follow-up
- Include applications alongside the operating system
- Rings for phased rollouts and targeted deferral
- Every exception with a reason and a review date
- A timestamp on each measurement, so its age is visible
- Failed installations with an error code rather than silence
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →From alert to work: the ticketing system integration
A management platform without follow-up produces alerts that nobody owns. They appear on a screen, disappear once the measurement returns to normal, and afterwards it is impossible to establish whether anyone acted on them. As soon as an alert becomes a ticket, that changes: there is a number, an owner, a status, and a point at which someone can ask why it is still open. That is why the integration between monitoring and the ticketing system largely determines whether an RMM delivers anything.
Technically, the integration is the simplest part. The platform sends a webhook or calls an API, the ticketing system creates a ticket with the alert as text, and the ticket number is sent back so the alert knows where it landed. In the other direction, you let the platform know that a ticket has been closed, so it can close the alert instead of leaving it open indefinitely.
The hard part is the rules around it, and that is exactly where standard integrations often fall short. The first rule is about merging. If a switch goes down, you don't lose one device but forty, and those forty alerts are together one problem. Without dependencies in the model, the queue gets forty tickets, thirty-nine of which close again as soon as the switch is back, and the technician has lost his morning in the meantime. A platform that knows which device hangs off which connection turns it into one ticket with forty affected devices.
The second rule concerns alerts that keep switching on and off. A disk that hovers around the threshold generates a new alert every ten minutes. A waiting period helps against this: only create a ticket once the state has persisted for a certain period, and only close it once it has remained normal for a period. The third rule concerns planned work. If maintenance is running, the associated noise should fall within a maintenance window set in advance, so that the queue doesn't fill up with alerts you caused yourself.
The fourth rule is the most dangerous: automatic closing. A ticket that closes on its own as soon as the measurement is normal keeps the queue clean, but also hides problems that resolve themselves and then recur. A disk that fills up overnight and has space again in the morning is a pattern, not an incident. A sensible setup does close such tickets, but tracks the recurrence and escalates as soon as the same device returns for the third time.
Some alerts never need to become a ticket. A service that has stopped and restarts on its own, a temporary folder that can be cleared, a print queue that jams: these are fixes the platform can carry out itself before anyone has to get involved. It is still sensible to log those actions too. A recovery that quietly succeeds hides a pattern, whereas the same service failing three times a week is precisely the problem you want to see. Self-healing should therefore always leave a note, and after a set number of repeats still raise a ticket.
Finally, the ticket must carry the device details. Not just the name, but the type, the owner, the location, the customer and a reference to the most recent measured state. A technician who has to look all of that up manually loses more time per ticket than the integration saves. If you want the ticketing side built or adapted by us, see building a ticketing system and custom helpdesk software.
An RMM has rights everywhere, which makes it a target in its own right
This is the subject that must not be left until the end when it comes to an RMM. By definition, a management platform holds far-reaching rights on every connected device: it can install software, execute code, stop services and open a session. That is not a design flaw but the core of the product. The consequence, however, is that whoever gains control of the management console has immediate access to everything attached to it. For an IT service provider, that means all of its customers at once.
This is not theoretical. The Known Exploited Vulnerabilities catalogue of the US agency CISA, which only lists vulnerabilities with confirmed exploitation, has included several management and remote-access platforms over the years. Kaseya VSA has been listed since November 2021 under CVE-2021-30116, flagged as used in ransomware. ConnectWise ScreenConnect was added in February 2024 with CVE-2024-1709, an authentication bypass that allowed an attacker with access to the management interface itself to create an administrator account, likewise flagged as used in ransomware. N-able N-central followed in August 2025 with CVE-2025-8875 and CVE-2025-8876, and in August 2026 with CVE-2026-18556 and CVE-2026-18577, where CISA notes that the second stems from an incomplete fix of the first.
The pattern extends beyond the platform itself. In an advisory from June 2025, CISA describes how ransomware actors used an unpatched installation of SimpleHelp to gain access to the customers of a software provider via that provider. This is the knock-on effect that makes a management platform particularly risky: one vulnerable system in the middle, and behind it every environment that depends on it. None of these vendors has done anything particularly unwise; they are notable because their product is designed to be very powerful. Every platform in this category carries the same risk, including a platform you have built for you.
There is a second way in which RMM software is abused in an attack, and it is often overlooked. In a joint advisory from CISA, the NSA and MS-ISAC, revised on 26 January 2023, attackers are described not as attacking legitimate remote management software but as using it: through phishing, they got victims to download ScreenConnect and AnyDesk as standalone executable files. Because such files need no installation and no administrator rights, they slip past controls that only look at installed software. For your own management landscape, this means keeping track of which remote management tools belong in your environment, and treating every other instance as suspicious. The full advisory is available at cisa.gov.
What this means for the design
If you accept that the platform itself is the target, the build order changes. Authentication is then not an afterthought but the first topic: multi-factor authentication for everyone, with no exception for the administrator who is in a hurry. The management console should not simply be reachable from the open internet, while the agents must be able to connect from anywhere; these are two different entry points and should be treated separately too.
Permissions deserve the same attention. A single role that may do everything on all devices is convenient but rarely needed. Permissions per technician, per client group and per type of action reduce the damage from a stolen account. For actions with a wide reach, such as a script that runs on all devices at once, an approval step by a second person is one of the few measures that genuinely stops an attacker with valid credentials.
If you manage multiple clients within the same platform, separation between them becomes essential. That separation should exist not only in the interface but also in the data and in the keys: a technician who looks outside their client group, whether by mistake or on purpose, should hit a wall rather than a filter. The same applies to scripts and policies, which are easily defined centrally and then end up with everyone. This is one of the few points where building your own has an advantage, because you define the boundaries yourself rather than deriving them from a vendor's model. The flip side is that tracking vulnerabilities and releasing fixes then also falls to your own organisation.
Logging should be written outside the platform. An attacker who takes over the management console would erase the traces first. Log entries written to a separate environment survive and make reconstruction possible afterwards. The same goes for alerts: if the platform goes down or is taken over, the notification about that should not have to travel through the same platform.
Finally, the legal framework, which has recently become more concrete. On 15 August 2026, the Cybersecurity Act (Cyberbeveiligingswet) entered into force in the Netherlands, implementing the European NIS2 Directive and replacing the Network and Information Systems Security Act (Wet beveiliging netwerk- en informatiesystemen). Organisations falling under it must register in the entity register, take appropriate measures based on a risk analysis, and report significant incidents within 24 hours to their CSIRT and the supervisory authority, with the board carrying ultimate responsibility. Whether your organisation falls under it depends on sector and size; parties that carry out ICT management for others would do well to check this explicitly. The NCSC describes the obligations and the registration process.
- Multi-factor authentication without exceptions
- Management console not open to the internet
- Permissions per technician and per client group
- Approval for actions with a wide reach
- Logging written outside the platform
- Alert channel separate from the platform itself
- Inventory of approved remote management tools
- Recovery plan in case the platform goes down
Frequently asked questions about RMM software
A monitoring tool detects and stops there: it measures, compares against a threshold and sends an alert. An RMM adds the ability to act. The same agent that measures disk usage can also run a script, install an update, restart a service or open a session to the device. So the difference is not in the measuring but in the permissions: an RMM is allowed to change the device. That makes it more powerful and at the same time more sensitive, because those permissions apply to every connected device.
No, an RMM looks at devices rather than people: which updates are missing, whether the disk is filling up, whether the backup agent is running, or whether disk encryption is enabled. Software that records what an employee does, such as active time per application, websites visited or keystrokes, falls into a different category with its own legal framework. If that is what you are looking for, see employee monitoring software. If you are building an RMM, it is sensible to deliberately keep those features out of scope and to be able to demonstrate that.
Because the report and reality drift apart. The platform reports that an update has been rolled out, while the device is still waiting for a restart, the user keeps postponing the restart, or the update has been reverted by another process. Meanwhile the risk shifts to the applications alongside the operating system: browsers, PDF readers, runtimes and utilities. Patch management only works when you can see, per device and per package, which version is currently running, when it was last measured, and why an update did not get through.
Technically, this is usually a webhook or an API call that turns an alert into a ticket, with a reference back to the device. The difficulty lies in the rules around it: which alerts deserve a ticket, which are merged into one, when a ticket closes automatically once the measurement is back to normal, and how you prevent a brief network outage from producing a hundred separate tickets. Without those rules, the queue turns into a log that nobody reads any more, and the real problem disappears into the noise.
By assuming the platform itself is the target. That means multi-factor authentication without exception for administrators, a management console that is not simply reachable from the open internet, permissions per technician and per client group rather than a single role that can do everything, scripts that may only run at scale after approval, and logging written to an environment outside the platform so that an attacker cannot erase it. CISA's Known Exploited Vulnerabilities catalogue includes several management and remote-access platforms, which shows this is not a theoretical scenario.
Often, yes, and we would rather say so upfront than halfway through. The market is mature: NinjaOne, Datto RMM, ConnectWise, Kaseya VSA, N-able N-central, Atera, Syncro and Action1 together cover the common management work, and open-source options such as Tactical RMM also exist. If you manage a conventional Windows and macOS estate, buy one off the shelf. Custom development only becomes interesting for equipment that does not accept a standard agent, for a management process that does not fit the data model of a package, or when you want to include management functionality in your own product.
Related services
Employee monitoring software
If you are looking for software that monitors what employees do, rather than the state of their device, that is a different category with its own legal framework. See building employee monitoring software.
Custom ticketing system
The queue in which alerts become work, with its own statuses, agreements and reporting per customer: building a ticketing system, or more broadly custom helpdesk software.
Custom maintenance software
If the focus is not workstations but installations, machines and periodic maintenance in the field, that question belongs under building maintenance software. A broader overview is available under software development.
Taking a closer look at your management landscape
Tell us how many devices you manage and how varied they are, what happens right now when an alert comes in at three in the morning, and how you verify that a security update is actually in effect. Those three answers usually show whether an existing package is enough, whether an integration around it is needed, or whether custom software is the most sensible route.