Least Functionality

At about two o’clock tomorrow morning a member of staff at a British insurer will log in to the policy system. It has a username and a password, like the rest of us. It will download yesterday’s transactions as a CSV file, which is the format systems use when they are not on speaking terms, open the finance system in a second window, and type the figures in. One field at a time. It will press Tab between the boxes and click Save at the foot of each screen, and it will go on doing so until the file runs out or the software house moves the Save button, whichever comes first.

It is a robot. To be exact it is a script that drives a screen, written by a capable developer who was asked to connect two systems and then forbidden the obvious way of doing it. I have run IT at an insurer, I now run a broker that has to plug into other people’s systems, and I have met this robot more than once.

Both systems came with a way of talking to each other directly. It is called an API. The firm paid for it, and it would have moved yesterday’s transactions before the robot had found the first box. It was switched off. The reason given was security. An industry that still settles a good deal of its business by emailed spreadsheet, under the dignified name of bordereau, was never going to find a CSV file undignified.

Half of that reason is sound. Software arrives with everything switched on, and every open interface is one more thing to patch and watch. NIST’s catalogue of security controls has an entry for the problem, numbered CM-7 and titled “Least Functionality”, which tells the owner of a system to provide only its essential capabilities and to “prohibit or restrict the use of” everything else. The CIS Controls and the card schemes’ PCI standard say much the same, and nobody sensible objects.

The other half is the word essential. The control leaves the organisation to define it, which in practice means a committee, and a committee tends to define as essential whatever it can picture. Every member can picture a person at a screen. Several were that person, in the days when the screen was green. An API offers nothing to picture: there is no desk, no chair and no login page, only one machine putting a question to another in a dialect neither would use in company. So the person at the screen is ruled essential, and the thing that would have made the screen unnecessary is ruled a risk. This takes a chief executive who cannot imagine the work being done any other way and, more awkwardly, a chief technology officer who cannot either.

What was refused and what was approved make an instructive pair.

The API would have been given a key. A key can be issued to one system for one purpose. It can be limited to named operations, tied to requests from a single address, changed on a schedule and cancelled in a second, and every call made with it can be logged along with the question and the answer.

The robot was given a job. It has a user account, because the screen will not open without one. Its password is typically set never to expire, because a password that lapses at two in the morning stops the night’s work and there is nobody awake to choose a new one. It is typically excused the second factor, because the code goes to a phone and the robot has not been issued with a phone. It can do whatever a clerk can see and click. The record of its night reads, in full: user logged in; user was busy. And it can be stopped dead by a change to the layout of one screen, which the vendor rarely thinks to mention.

As a piece of underwriting, this declines the warehouse with the sprinklers, the alarm and the visitors’ book, and writes the one with the key under the mat, on the grounds that everybody on the committee has seen a mat. No underwriter would keep his pen for long after it.

The firm now pays three times: for the API it may not use, for the robot, and for the robot’s keeper. The keeper is the capable developer from the second paragraph, who is the only person who understands the script and has therefore become too important to promote.

This has changed how I read the statistics on unused software. Zylo’s 2026 index, drawn from more than forty million licences, finds 36% of them unused, at an average cost of $19.8 million a year to each enterprise in its data. One practitioner estimate puts the share of purchased capability in active use below 30%. I used to take these as a measure of sloth: seats nobody logs into, modules nobody opened. A good part of it will be. But none of the reports I have read has a column for “switched off by order”, so nobody can say how much of the idleness was a decision, and I include the people who made the decision.

On the utilisation report, meanwhile, the API shows as paid for and never touched, and any competent adviser would tell the firm to stop paying for it. The robot’s account shows as a model employee, in every night and never once off sick. By the only measure anybody takes, the firm’s keenest user is the one that was never given a desk.

The research on why people use so little of what their employers buy has reached the same place by a more respectable road. Its standard review, by Jasperson, Carter and Zmud in 2005, found users working within “quite narrow feature breadths”. A later study by Bagayogo, Lapointe and Bassellier found that in large, tightly specified systems a new use of a feature tends to begin only when a supervisor or a governance body starts it. Taken together, they suggest that the working feature set of an insurer is bounded by the imagination of its steering committee.

The same committees have lately bought AI assistants. Redress Compliance reports, from 60 to 80 reviews of enterprise spending, that 71% of AI add-on seats are idle within two quarters of purchase. That is one source and I would not hang a budget on it, but I find it easy to believe. A firm that will not let its policy system answer a question from its own finance system has bought a machine whose whole function is to answer questions from whoever asks. My guess is that somebody on the committee asked what it would do with client data, nobody could say, and it was switched off pending a paper. On that one I think the committee was right. The robot, I notice, is still typing.

There is a test a board member can apply without learning what an API is. Ask for the list of user accounts that belong to nobody with a pulse. For each, ask what it does at night, what it is excused that a human user is not, and what was switched off to make it necessary. If the answer to the last question is something the firm is still paying for, then the security policy is spending money to make the firm less secure, and somebody should be asked to explain the essential part.

As far as I can find, nobody has measured what this costs. The security frameworks are well documented and the workarounds they provoke are not. I can offer one data point. It logs in at two.

Sources: NIST SP 800-53 Rev. 5, control CM-7, “Least Functionality”; CIS Controls v8, safeguard 4.8; PCI DSS v4.0.1, requirement 2.2.4; Zylo, 2026 SaaS Management Index; Accucia, The Adoption Gap (2026); Redress Compliance, The Shelfware Report 2026; Jasperson, Carter and Zmud, MIS Quarterly 29(3) (2005); Bagayogo, Lapointe and Bassellier, Journal of the Association for Information Systems 15(7) (2014). The vendor and practitioner figures are theirs; the robot is the author’s own observation.