How to lock out normal (non-admin) users during software installs?

Before we get going I want to make a pedantic point, more for the benefit of the general readership than yourself.

we just push it via SCCM

SCCM is a pull-based technology. I know what you meant but I find that with my tier-1 guys, every opportunity I get to emphasize that SCCM is not a push-based technology helps them understand it quicker.

I've contacted the vendor about it, but they just say it's a known issue and there is no fix or workaround for it

That is too bad as it sounds like the cause of this issue is the embedded card authentication program. Keep on the vendor, maybe they will actually fix their software.

On to a real answer - I see a few possible solutions for you, none of them particularly good.

• Configure a Maintenance Window for these clients so your initial reboot to remove the clients from their write filter, your actual payload and the resulting reboot all happen off-hours when employees are not present at the terminals. This seems like the least painful option. No need to make SCCM more complicated than it already is.
• Create a Local Group Policy template that adds a security group to the Deny Logon User Right and then assign/un-assign it as part of your application deployment.
• Use PowerShell to set the Deny Logon User Right. I believe the PowerShell Community Extensions (PSCX) has the Set/Get-Privileges cmdlets which will let you manipulate User Rights Assignments
• You can use the API if you want. Here's an example.

It seems no one touched on the possibility of using a task sequence to handle this, so allow me to list the benefits (assuming you're not really familiar with them in general, but please read even if you are):

If everything you install and configured is handled w/ SCCM, you should be able to use a task sequence to accomplish this. Primarily for OSD, using a TS is not only for OSD and can provide the following benefits:

No logging onto the workstation

A TS executes before winlogon.exe runs, so there is no possibility of a user inadvertently logging on, as there is no log on window. Which brings me to my second point:

Custom background screen

You can provide a splash screen that says maintenance is being performed, or whatever you want it to say really.

A TS is really just a glorified script, but it has a lot of functionality and is put together in a way as to decrease development time, and I've found use cases beyond OSD.

It sounds like you already have a script to do what you need done, so you should be able to put that into a TS with minimal debugging and get going.

You haven't specified if the SSO software uses Active Directory credentials, so a solution would be to make use of Active Directory's "Logon Hours" function. It's at a per-user level, but can easily be scripted in Powershell (this being an example). Basically, set the logon hours to "deny" logon at your SCCM update window and the users will be unable to log into the clients while SCCM does its thing. You'll need to have that first forced reboot which will log them out (the logon hours function doesn't work on logged-in users), but it would otherwise be painless to implement.