Well, it should first be stated that (unfortunately), the error message you are dealing with ("A Security Package Specific Error Occurred.") is not quite clear, is not well documented, does not contain enough information to troubleshoot, and apparently it can come from multiple places and have several different causes. and, as it is a Microsoft-generated error, we cannot do anything about these issues with the messages.
I wanted to explain the above in order to make the following point: If, in your original post, you were getting "A Security Package Specific Error Occurred." occasionally, while in your new configuration, you either get it all the time (with one setting), or not at all )wit the other setting), then most likely the original cause (for the occasional error) is something completely different from the new cause (for the consistent error) - although it has the same text.
And, does it mean that we are changing subject here? Because, with the one setting you described, you get the desired results, or not?
Anyway, to your question: When UseCustomSecurity is 'false', we do not attempt to influence the COM/DCOM security from our OPC client classes. As a result, settings that get used are those given by that either the operating system (including the app setting in DCOMCNFG), or the hosting environment (CLR).
When UseCustomSecurity is 'true', we attempt to configure the COM/DCOM client security to the settings that (in our experience) work well in most common situations. When UseCustomSecurity is 'true', you can also use other settings (such as TurnOffCallSecurity) to influence what happens. If you like, I can look up details of what the affected COM securitys are, but frankly, it is not something that makes much sense to those that are not Microsoft security experts, and usually it's easier just to experiment and find the combination that works (which you have probably found already).
Best regards