When should you push back on a software vendor’s IT requirements?

A software vendor is ready to install an update. Their instructions say to give the installer administrator access and turn off endpoint protection if the installation fails. The office manager wants the update done before the next business day. The vendor’s request is easy to forward to IT, and a broad exception can sound like the fastest way to get everyone out the door.

I’d slow down long enough to ask what the installer actually needs. Administrator rights on one server for the duration of an update and standing administrator access across the business are different decisions. The vendor may have a good reason for the first one. The owner should be able to understand the reason and know when that access ends.

Ask what they need to change

Have the vendor identify the machine, application and step that requires elevated access. Ask whether an IT administrator can start the installation while the vendor guides them, or whether the vendor needs to operate the console. Find out how long the work should take and who can confirm the update succeeded.

In this example, the answer might be that the installer needs to stop an application service and update files on the server. That gives IT a job to prepare for. If the vendor says it needs ongoing administrator access, ask which ongoing work requires it and whether the account can be limited to that application or machine. A support requirement should be specific enough that someone else can explain it when the vendor contact is away.

Treat a security exception as a separate decision

If protection blocks the installer, capture what was blocked and ask the vendor to verify the installer and its source. “Turn everything off and try again” leaves too many things changing at once. Find out whether the vendor has documented a supported exception for the specific file, process or operation. IT can then review how narrowly it can be applied and whether there’s a safer way to complete the work.

If the only supported path really does require temporarily lowering a protection, decide who can approve that and what would make you reschedule. For example, if the installer cannot be verified or the business cannot restore the system if the update fails, pause the work until those issues are resolved. Agree on the affected system, the time window, who will watch the change and how to restore the control. For remote support, use an approved access method and record who connected. CISA’s guide to securing remote access software covers risks and controls for those tools.

Decide how you’ll know the work is done

Before the update starts, pick a task someone in the business can run afterward. For a scheduling application, it could be opening a test appointment and confirming the front desk can still print the day’s schedule. IT can separately verify that the temporary account was disabled or its elevation removed, the remote session closed and any security exception removed or restored to the approved state.

If the vendor needs to come back tomorrow, make a fresh access decision for tomorrow’s work. If a permanent exception is necessary, record why it exists, what it covers, who owns it and when it will be reviewed. Without that record, a future technician may remove a setting the application depends on or keep an exception long after the vendor stopped needing it.

I’d send the vendor a simple reply: “We can arrange access for the update. Which system and permissions do you need, what requires the exception, and how will we confirm the application works afterward?” A vendor who can answer gives the office enough information to approve a sensible change. That’s a better starting point than asking the owner to sign off on “admin access” in the abstract. For the broader question of who should coordinate the work, see IT vendor coordination.