I don't know. I found the argument convincing that even naming the breach "identity theft" is beginning to push responsibility away from Equifax and make it seem a personal problem of those affected, or a general societal phenomenon. When in reality it's just Equifax's poor security practices.
As you probably know, the exploit basically is using Java's ability to dynamically execute code from JVM bytecodes (supplied via XML in this case, but that's just an implementation detail). Once you get remote code execution ability, it's game over for most Java backend apps, because these are executed in a single process/address space and thus lack basic process isolation. Even if JAAS were used to propagate authorization contexts within the Java backend, typically (almost always) Java apps operate in such a way that a single database identity/credential sets is used for any and all database access.
Dynamic bytecode execution is a core feature of Java and other JIT execution environments, so you can't use straightforward NoExecute bits (provided by hardware and supported by OS loaders to disallow calling into dynamically allocated memory) to prevent this from happening, and can't contain/isolate execution paths with authorization contexts either. For these reasons, I think this breach should make banks and other financial institutions rethink their Java strategies mid- to long-term.