Is the software behind your client sites still getting security updates?
Most agencies cannot answer this for their own client list. It takes an afternoon by hand and about a minute when the projects already know.
Of the sites you maintain, how many run software that still receives security fixes? Better to know before a client asks.
"Are they up to date" is a different and softer question. This one is narrower. When a vulnerability lands in PHP next month, will a patch exist for the version this site is on, or has that version been abandoned by the people who wrote it?
Most agencies cannot answer, and it is not negligence. Answering by hand means opening each hosting account, reading each site's runtime, then cross-referencing every one of those against a support calendar that changes as versions age out. It is an afternoon of work that is out of date the following week, so it never gets done twice.
Why the answer is bigger than PHP
The runtime is the obvious part. It is also the part that flatters you, because a site on a supported PHP feels safe.
A Laravel project carries dozens of Symfony components underneath, and those have their own release cycles that end on their own dates. So do the packages you added yourself three years ago and never thought about again. A project can sit on a perfectly supported Laravel and still depend on a component series that stopped receiving fixes months ago. "We are on a supported Laravel" is not the whole answer, it is the first line of it.
The same is true in the other direction. A site can run a dead PHP quietly for a year without a single symptom, because nothing breaks when support ends. Nothing happens at all, which is the problem.
What the answer needs to look like
For this to be useful rather than alarming, it has to arrive in a specific shape.
It has to be per project, because that is how you bill and how you have the conversation. It has to name the date support ended or ends, so "old" becomes something you can put in a sentence to a client. Knowing PHP 8.1 is finished is only half of a decision, so it also has to say what to move to. And it has to update itself, because the whole reason nobody does this by hand is that the answer expires.
That last one carries more weight than it looks. A version dies when a date passes, whether or not anybody deployed, so any system that only notices during a deploy will tell you a site is fine right up until the moment somebody touches it.
What this changes with clients
The uncomfortable conversation about a maintenance retainer usually goes badly because both sides are arguing about a feeling. The agency feels the work is real. The client sees a line item and a site that looks the same as last month.
A list of the client's own sites, with the software behind each one and the date each stops receiving security fixes, changes what is being discussed. You are no longer defending a fee. You are showing a schedule, and the schedule has dates on it that arrive whether or not anyone acts. Some of those dates are next quarter. That is the conversation.
It also changes what you inherit. When a site arrives from another agency, the first honest question is what is actually running under it, and the second is how long that has left. Both are answerable on day one instead of after the first incident.
In Unolia this lives in a project's Versions area: what each project runs, what it ships, and where each version sits against the support windows published by the people who maintain it. A runtime past end of life stops being a badge and becomes an issue on the project, so it shows up in the morning alongside everything else that needs a decision.