In general, you need a specific architecture of your app AND a specific environment for this to work.
First, you need a form that is always open. It COULD be a switchboard form or dispatcher type form. It could also be a form that gets launched and immediately makes itself invisible. This form needs a timer that wakes up every so often - every 15 or 30 minutes is slow enough to not overload your system. The timer needs to step through the Forms collect to try to close each open form. IF you have the problem that your users leave active forms open (i.e. bound to some underlying record) you might need to look at the Form_Unload events to assure that if this phantom form tries to shut things down, it can. Whether you have a public semaphore somewhere that says "die now" or some other mechanism becomes a matter of trial and error. However, once all the forms are closed except the hidden one, you can then try an Application.Quit from that form, and ITS Form_Unload routine should allow it to be closed.
The other alternative is that EVERY form has a timer and you have a flag in every form's declaration area that gets reset any time some action occurs within the form to reset that flag. As long as your folks don't have the habit of opening multiple forms, this isn't bad because one or two timers with long intervals is not a burden. Several forms with short intervals can become a burden to your system. There is no guideline that says "x timers with interval of y is too much of a burden." That decision depends on too many factors.
Second, IF your site IT shop is hyper-active, they might impose some site policies to lock idle terminals. It can happen that a locked terminal would thwart this shutdown method, depending on just how active your IT group happens to be.