This is a tricky little problem in security.
IE, like many tasks under Windows, is written via "pure code" techniques. This means that they use advanced memory management to instantiate the process. If you open a web page and without closing it, open another, you have ONE copy of the "pure" section of IE and two copies of the working memory ("impure" or "dirty") area. So when you switch from one page to the other (both still being open), it is merely a matter of diddling a few memory pointers to get to the right context.
What becomes trickier is, WHY is that other page open (if your Access-based task didn't open it)? Even if you are the owner of the machine and its only user, you open different session threads to run Access and IE simultaneously. If the already-open Window wasn't started by Access but rather was you doing a separate act of browsing, those two threads look different to Windows. It might, as a security measure, object to you trying to close a session from a thread that didn't open that same session. This is a razor-thin issue in that it is ALL you (if you are the only user on the machine) but Windows still has this internal mandate to keep threads separate based on complex criteria.
I am not deeply familiar with IE internals, but in theory the solution is to include IE in your app's reference list (see the link below) and then manipulate the pages to find the one you want and then make it current. Do not try to close the IE page you don't want. Instead, try to manipulate the page you DO want and just leave the other page alone.
In this ArticleNavigate to a Webpage with VBAVBA Coding Made EasyOpen URL and Enter Data in Form Using VBAGetElement in IE using VBAInteract with IE using VBASendkeys to Internet ExplorerRun Internet Explorer in BackgroundSelenium & VBA This page contains coding examples for automating Internet...
www.automateexcel.com
You can find more by searching the web for "Use VBA to control IE" and see if anything there helps you.