10 shifts reshaping IT operations in 2026

I have a rule about trend lists, which is that I don't read them.

They're mostly written by people who read other trend lists. You can tell, because every item is a noun phrase ending in "-ification" and none of them cost anything to be wrong about. "Security will become more important." Thank you.

So this is my attempt to earn an exception. Everything below comes from what IT practitioners are actually spending their working hours on, which is a different thing from what vendors are announcing. Each one gets a real number attached. Where I think the received wisdom is wrong, I say so.

One more thing before the list. These are not ten separate developments. Four of them are the same underlying move showing up in different parts of the stack, and I'll point at it when we get there.

1. AI stopped being embarrassing, and checking its work became the scarce skill

Twelve months ago, people discussed using AI at work in low voices, and almost nobody admitted to shipping code they hadn't fully read. That stigma is gone. In one year-over-year survey of IT admins, the share saying they definitely don't find AI useful in their own job fell from 30% to 11%, and the combined "yes very much" plus "yes somewhat" responses reached 84%.

The capability is real, and specific enough to be worth citing. One diagnostic pass over a five-minute log window containing more than 600,000 lines correctly identified a real-time audio engine CPU overrun, a broken third-party plugin link, and a license check that hung for exactly 15 seconds at 12:55. The impressive part was not finding errors. It was correctly clearing a red herring: a background process logging the same error pair 2,500 to 3,000 times per second, which the model called a contributing drag but not the cause, because it had never touched the application that froze.

Now the other column. Around 45% of AI-generated code across 100-plus tested models ships with an OWASP Top 10 vulnerability. Roughly 1 in 10 samples passes a security review, even though most of it runs fine. Up to 1 in 5 package references from some models point at packages that do not exist, and attackers have started registering those names and filling them with malware.

So the scarce skill stopped being the writing and became the checking. The old heuristic that well-written work is trustworthy work is broken, permanently, and I don't think our profession has absorbed that yet.

2. The assistant got hands

This is the one I'd have dismissed a year ago.

Connecting an AI to your actual IT systems through a tool protocol turns it from an advisor into an operator. What that looks like in practice: asking how many devices can run a new OS release and getting a correct answer of 16 out of 17, because the model cross-referenced hardware models against requirements it went and found on the open web. Sending a remote command to a named person's laptop given only a username, where the model inferred the right tool, resolved the username to a serial number, executed, and then checked whether it had worked by comparing timestamps, which nobody asked it to do. Chaining three unrelated systems in one request: find devices with a vulnerability score above 9, identify the owner, check whether I have a meeting with them in the next two weeks.

One person built a full connector covering an entire vendor API surface in about 15 minutes for roughly $20 in tokens, after hand-building a two-endpoint proof of concept first.

Here's the part that should worry you, and it's why this belongs on the list rather than in a demo video. The model's understanding of what a tool does, and whether it is destructive, comes entirely from a short text description a human wrote. Genuinely just a string. One team admitted their own descriptions were inconsistent, with prominent warning language on one destructive action and none on a comparably destructive one. There is no established practice for how those descriptions should be written. The safety mechanism, right now, is prose.

3. Passwords are being designed out, slowly and at some expense

The rotation policy everybody recognizes: forced changes every 90 days, users appending 1, then 2, then 3, running out of digits, then forgetting which one they landed on.

The replacement is genuinely better. Badge tap login cuts a sign-in from about 12 seconds down to about 2, which sounds trivial until you multiply it by a shift worker logging into shared machines forty times a day.

My position, and it's less popular than it should be: the transition costs more tickets than the steady state saves, for something like eighteen months, and almost nobody budgets for that. The registration prompt is the proof. When the configuration lands on an existing machine, users ignore the prompt, or dismiss it, or report it as a virus. Then they open their mail client, get asked for a password again, and file a ticket saying single sign-on is broken. The streamlined setup flow only helps brand-new machines. For an existing fleet there is no good way to nudge anyone.

Also worth knowing before you plan anything: this was announced in 2022, and the setup-assistant integration announced in 2025 was not actually deployable with the two major identity providers until May 2026. Google Identity still does not support it at all, which structurally blocks a large number of organizations from participating.

4. Standing admin access is on the way out

The best sentence I've read on this in years: standing secrets on endpoints are an architectural problem, not a hygiene problem. No amount of rotation discipline fixes a design where the secret should never have been on the device.

What replaces it is access with a timer. One implementation grants local admin for 20 minutes after a user picks a reason from a short dropdown, works offline via a local timer, and can be revoked three independent ways: the local timer, the identity provider's own timer which also re-asserts "no admin" as the default on every check-in, and a management check that catches anyone still holding admin past expiry. A reboot revokes it immediately regardless.

The security argument is clean. Worst case, if a laptop is compromised, the attacker can grant themselves admin, which they were already allowed to request.

But the detail I keep thinking about is organizational, not technical. That team shipped deliberately without an approval gate, because removing standing admin had already used up all the internal goodwill they had. Their reasoning was that every increment costs political capital, so don't let perfection be the enemy of good. That's the most honest thing in this entire article.

5. Change control became a merge request

Most fleet-management scripts are unversioned production software that happens to have a .sh extension. They run as root, fire on every enrollment and inventory check, and get treated with none of the discipline any other production code would receive. Blast radius equals your fleet.

One admin inherited about 60 undocumented scripts with no categories and no notes, including one named "test. Do not use." that was live in three policies. Another carried an internal comment reading "don't touch this part." He touched it.

The fix that has become standard is Git as the source of truth, CI as the deployment mechanism, and the management platform as a target only. Protected branches do the real security work, because credentials only inject on protected branches, so an unprotected fork literally cannot reach them. Deletion runs in two phases, with a marker set 72 hours out and a nightly job doing the actual removal, because hard-deleting a script attached to 200 policies is a great way to have a very bad morning.

The payoff is a sentence you can say out loud: when someone asks who broke that script last Tuesday, you have an actual answer.

6. Declarative won, and failure went silent

Instead of issuing commands, you declare the state you want and let the device converge on it. Legacy update-scheduling commands are being removed, so this is not optional and not distant.

When it works it's elegant. A wrapped legacy profile can transfer management in place, without removing and reinstalling anything, so users see no prompts at all. Some teams run the takeover overnight and nobody notices.

When it doesn't work, nothing tells you. If a declaration's dependency is missing, or a device fails a stated condition, the declaration simply does not apply and no error surfaces to anybody. One team that had migrated around 300 profiles discovered, by internal testing rather than documentation, that once a device holds more than roughly 10 to 15 wrapped profiles the subsystem locks up and needs a manual reboot to recover. There is no documented limit. There is no warning.

Which brings me to the position I'd defend hardest in this whole piece: adopting declarative management without also adopting monitoring makes your operation worse, not better. You've traded loud failures for silent ones. Blocked applications now bounce in the Dock with no dialog whatsoever. A content cache server can disappear for two weeks with nothing to tell you.

7. Zero-touch became the floor

One organization went from over two hours of hands-on IT prep per device plus more than an hour of user setup, to zero IT touch and about 30 minutes of user setup. That change let them onboard roughly 70 new people at once, which they describe as impossible under the old process.

Provisioning is basically solved. Installing the same ten apps took 3 minutes 9 seconds with a purpose-built tool versus about 15 minutes 29 seconds with a hand-rolled script loop.

And then everything hard moved into somebody's living room. A user closing the laptop lid mid-download. A minimum home internet requirement of about 50 Mbps written into the process as a prerequisite. Fifty devices provisioning at once saturating the office network during a hiring wave. New hardware sitting in a box for weeks because a cable was missing and nobody followed up.

8. Everybody runs two of everything

Almost every organization now manages more than one device platform, and most manage three or more. Most also run two or more separate management tools with independent agents just to cover the mix.

One major cross-platform vendor runs roughly 20,000 Macs against about 500,000 Windows PCs internally, and their own product manager said plainly that their IT does not manage Macs very well. Admins commonly keep an agent from a previous tool around purely because it executes faster than the primary channel, so even fully migrated fleets end up dual-agent by necessity.

The cost that never gets counted: a new IT hire spends real time just learning how your particular tool arrangement is wired, and that shows up directly as slower ticket resolution for the person waiting. Tool sprawl is a resolution-time problem before it is an architecture problem.

The consolation prize is money. One org reconciling licenses after a migration found it was paying for about 4,000 device licenses against roughly 3,500 actual active devices.

9. Attention is the binding constraint, not capability

A careful identity migration gave 743 identified accounts a 30-day self-service window, with delivery confirmed in mail logs and targeted follow-up reminders to people who had received the first notice. Sixty-three accounts moved. The rest arrived on cutover day and got worked by six to ten people for a full day.

The corroboration is what makes this a trend rather than an anecdote. A government IT org sent a 30-day notice, then a 7-day notice, and ended up phoning individual users. Another organization ran a near-identical rollout for 2,000 users and got a near-identical result. And a compliance team that skipped the friendly framing entirely, telling staff bluntly to remove personal data from a government email address, got the same low voluntary adoption anyway.

Read that last one twice. The tone of your message may matter far less than anyone in marketing wants to believe.

I've come around to thinking voluntary self-service windows are a comfortable fiction, and that the humane option is a short window with a hard, clearly explained deadline. Long windows don't reduce disruption. They defer it into a single terrible Wednesday.

10. Support is being graded on how it feels

One team ran a technically flawless laptop refresh. Drop-shipped, self-configuring, nothing to install. It still made people anxious, because they were afraid of losing logins and files and disrupting client work. Afterward, nobody mentioned that the technology had worked. What they talked about was being in a room together and not feeling alone with it.

I resisted this idea for about six years, because it sounds like the opposite of engineering. Compare two messages carrying identical information: "we have received your request and will respond when we are able" against "hey, saw this, I'm on it." Same queue, same latency, completely different experience of being a person who needs help.

There's a related argument I initially found precious and now think is correct, which is that calling people "users" changes how you treat them. Call someone a user often enough and you start treating them like one.

Four of those were the same thing

Time-boxed admin instead of trusted admin. Merge requests instead of careful editing. Declared state instead of remembered commands. Structured intake instead of a well-written ticket.

Every one of those takes a control that used to live inside a person's discipline and moves it into the structure of the system. That's the actual through-line of 2026, and it's a good direction, because discipline does not scale and structure does.

What didn't change

People still don't read anything. Local accounts still need a password, and there's no fully passwordless path yet, so anyone promising you one is selling. Hand-written scripts are still the correct answer whenever you need genuine 100% reliability with error handling a human wrote, and the question that decides it is still "consider the consequence of a wrong answer." And the hardest part of any large technical project is still the data, the processes, and the people around the technology.

Where I might be wrong

Items one and two. The economics are not settled. One practitioner hit the usage cap on a new top-tier plan within three hours and warned that AI subscriptions may get expensive enough that a human is cheaper than tokens. Another organization bought five team seats and found a month later that nobody was using them, because everyone had kept their personal accounts. There's a serious argument that current scaling needs a multi-exponential increase in compute and energy that does not exist, and that we're heading for a third AI winter. I don't think that happens. I would not bet my roadmap on being right.

And there's one question nobody has answered. If AI absorbs the level-one support role, where does the next generation of level-two engineers come from? That grunt work was how people learned the fundamentals. I've heard the problem named several times now and I've never once heard an answer.

Which is a reasonable note to end on. The profession spent a decade automating the machines, and has only recently, reluctantly, started designing around the humans. Most of the interesting problems left are in that second category.

---

Foqal builds conversational ticketing for IT teams working in Slack and Microsoft Teams.