I concur that the 2nd statement is not True. HOWEVER, I do at times have to revoke and reissue my Tokens to change environments in Eclipse. Meaning if I change from SB to Prod as my SDF target I will get a error, go revoke and reissue my token in eclipse and it works.

Actually, the behavior you describe is precisely why the second statement is true. 😉 The token-related behavior you describe is the problem. The root cause is the use of the Production role and its Sandbox clone concurrently. That's the issue. The "solution": create a different SDF role in Sandbox and issue a new token the user with that new role. Same SDF-bundle integration. Problem goes away. I say "solution" b/c to me it smells like a workaround (see footnote). (FOOTNOTE. Warning - what follows is conjecture. Fun! But impossible to substantiate. At some level, account-user-role is being treated as a globally unique key. Probably NetSuite's TBA session-management registers/identifies the session with a compound key on account-user-role, without respect for the environment. That would be fine if each account had one environment. But since there can be many environments, and since authentication is environment-specific, mayhem ensues when one environment's session is still active, and and a second environment attempts to initiate a session with the same account-user-role combination. I'm guessing that even one instance invalidates the second token--and, indeed, in my experience, this happens once, and the token can't be used [need to revoke and create a new one]. The solution of creating a new role is really a workaround [it shouldn't be necessary]: if one creates a new role in the SB and uses it for SB tokens, those tokens can never "overlap" with those of production, since the role in the account-user-role key would only exist in SB. Again, this is all conjecture, in fun. One way to test the notion of account-user-role as globally unique key would be to create a new SDF role in both environments immediately after a SB refresh, in the hope that it would take the same Internal ID [sometimes that happens]. Then, issue a new token to the same user in each environment separately, using the newly created role. If the problematic token-related behavior occurred, then we would know that the root cause relates to the use of account-user-role as a globally unique key to identify the session. It wouldn't even have anything to do with the fact that the Sandbox had a "clone": it would be the coincidence of a role with the same Internal ID, pointing to the problem of a not-quite-globally unique key.)