Transparent Mode SSO cached credentials

It works as intended, and is that way for a reason.  Not doing it that way means a lot of updaters and non-browser access stops working.  The alternative could be a very large exception list with dozens of apps and websites in it that an admin would need to maintain.  Or in the case of HTTPS, users would just have to get used to the fact that occasionally they will go to a (HTTPS) website and get "Page cannot be loaded" until they go to a different website (HTTP) first.  Or worse, they go to HTTPS facebook and continuously browse there but every 5 minutes it stops working until they go to an HTTP site.

Other authentication mechanism have different restrictions.  If you use the authentication Agent then you won't have this problem because authentication is no longer tied to the restrictions of the HTTP standard and how well app developers have implemented it.  If you have many users on a single computer, or have non AD devices, than using the Browser login page may be a good option for you.

It sounds like you are working for a company with unusual restrictions - no logging for example.  While being super secure and private are important considerations, please understand that your requirements are different from the majority of UTM users.  There are always trade-offs with security.  Increasing security also means increasing cost, decreasing convenience, different levels of surveillance.  For many places, more security means more tracking (think US gov't) and for you it means less.

We do our best to find a balance that works for most people.  We use out own products.  I hope that it works for you.  And if it doesn't please raise a feature request through feature.astaro.org or contact Sophos support.  Priority of features is based on customer demand.

I wrote a somewhat longish reply but chose to delete it anyways as I think this is the wrong place for it.

That being said, you have to realize that your sales reps are actively pushing the UTM as a full-fledged enterprise-ready TMG replacement. No offense meant, but it's far from that. I can, off the top of my head, tell you at least five bugs (features as you might call them) that render your product unfit for enterprise use (The OWA sign-out bug, just to mention the most serious one, see 1 and 2. We've opened a support case for that one and haven't heard from you guys in weeks.)
I know what I'm talking about as we've bought a 150 user VM license to evaluate the UTM as a TMG replacement in one of our departments before deciding on a product for campus wide deployment.

Back to the topic, I realize that the cached credentials thing is meant as a convenience feature. Anyways, NOC / security admins should be free to choose whether they want to use such a feature or not. We have a simple policy for unauthenticated access: We do not allow it. That means, just because a smart device was able to successfully authenticate yesterday, it shouldn't be granted unauthenticated access to HTTPS resources today. It doesn't matter if that's inconvenient to the end user or not.

I wrote a somewhat longish reply but chose to delete it anyways as I think this is the wrong place for it.

That being said, you have to realize that your sales reps are actively pushing the UTM as a full-fledged enterprise-ready TMG replacement. No offense meant, but it's far from that. I can, off the top of my head, tell you at least five bugs (features as you might call them) that render your product unfit for enterprise use (The OWA sign-out bug, just to mention the most serious one, see 1 and 2. We've opened a support case for that one and haven't heard from you guys in weeks.)
I know what I'm talking about as we've bought a 150 user VM license to evaluate the UTM as a TMG replacement in one of our departments before deciding on a product for campus wide deployment.

Back to the topic, I realize that the cached credentials thing is meant as a convenience feature. Anyways, NOC / security admins should be free to choose whether they want to use such a feature or not. We have a simple policy for unauthenticated access: We do not allow it. That means, just because a smart device was able to successfully authenticate yesterday, it shouldn't be granted unauthenticated access to HTTPS resources today. It doesn't matter if that's inconvenient to the end user or not.