EA_Leeuw, I also began running into this issue as a full block on April 11th 2026 and I decided to do a more detailed analysis of the traffic over my network to have a better understanding of the root cause of the issue because it occurs on both Home Networks and Hotspots intermittently while happening much more often on non-hotspots (as observed/noted previously).
BACKGROUND
I ran into the 105-80190000 error from the first day I bought the game in mid-late February 2026, but it would typically let me create a session after rebooting my console 1-3 times while still using my WiFi, so I didn't think too much of it, but after I reached Chapter 6 I was unable to get past the error even after many restarts.
This is what I've concluded from my analysis:
This is not particularly a client-side network issue, or an ISP/firewall blocking the handshake; rather there is an issue with the response time of EA backend infrastructure and it should probably be escalated to your infrastructure or backend engineering team for review.
MY SYSTEM INFORMATION
Platform: Nintendo Switch
NETWORK DETAILS
To play the game I use an AT&T Router linking to Fiber Internet
NAT Type: B
All testing was done using Raspberry Pi as an access point with an ethernet uplink/WiFi uplink to the same AT&T Router or mobile hotspot uplink also AT&T based. No changes were made to the network/firewall, all alterations to speed were run through the Raspberry Pi as it intercepted traffic and then forwarded it to the Mobile Hotspot/AT&T Router.
Networks tested:
SUMMARY OF FINDINGS
Online session creation fails due to a race condition in EA's backend session preparation pipeline. The Switch reaches the Blaze session server and completes authentication faster than EA's backend finishes preparing the session. When the Switch presents its auth result to the Blaze Server, EA's backend is not yet ready to validate it, returns an unexpected response, and the Switch aborts the connection with a TLS Encrypted Alert.
Artificially slowing the network connection (adding 30ms and 50ms and 75ms latency via Linux traffic control) improved the success rate from ~2% on base ethernet to ~40% with a 30ms delay added and then 100% with 75ms added. So higher natural/artificially added latency confirms that connection speed — not network configuration — determines the outcome. I ran 100 tests across the three network settings mostly with my natural ethernet based connection.
Here's the breakdown:
Notice that slower connections using a cellular/hotspot connection or WiFi work because they give EA servers time to respond when the Switch expects and create the session correctly. Ethernet connections were 100% successful with artificial latency of 75ms added, but it improved as more latency was added when it almost never worked with its natural low latency.
RACE CONDITION EXPLANATION
The bug is a timing dependency between two EA backend systems:
1. The Blaze session server accepts the connection and begins session setup
2. EA's auth backend (accounts.ea.com coordination) prepares the session credentials in parallel
On low-latency connections the Switch completes its auth steps and returns to the Blaze Server before the auth backend finishes. The Blaze Server receives the Switch's auth presentation but cannot validate it because the backend preparation is not complete. It returns an error response, the Switch sends an Encrypted Alert, and the session fails.
On high-latency connections the additional network delay gives EA's auth backend enough time to finish. The Switch's auth presentation arrives after the backend is ready, validation succeeds, and the session completes. This is consistent with all observed data across 100 captures.
EVIDENCE AVAILABLE
I have the following available to share upon request:
I am happy to provide any of these to your engineering team, but they may also be able to reproduce the behavior detailed above on their own just from this information.
Thank you for your time and attention to this. I hope this report helps your team identify and resolve the issue for all affected players.
Edit-
Adding some detail about the flow of network traffic during the failures/successes:
DETAILED FAILURE SEQUENCE
Every failed session follows this exact sequence:
1. Switch queries spring18.gosredirector.ea.com and is assigned a Blaze Server
2. Switch initiates TLS connection to assigned Blaze server — handshake completes successfully
3. Initial Application Data exchange occurs between Switch and Blaze Server
4. Switch simultaneously contacts accounts.ea.com, qoscoordinator.gameservices.ea.com, Nintendo auth servers, and other EA services during a multi-second gap
5. Switch returns to Blaze Server with auth result
6. Blaze Server responds with Application Data
7. Switch immediately sends a TLS Encrypted Alert — indicating it received an unexpected or invalid response
8. Switch sends TCP RST to Blaze Server
9. Blaze Server sends FIN ACK (terminating the connection to the Switch)
10. Session creation fails and players get the "Account settings has changed..." error message.
In successful sessions, Step 7 does not occur, instead, the Switch receives a valid response and the Application Data exchange continues for ~2-3 additional seconds until the session is fully established.
Also, "Blaze Server" refers to any of the following 4 servers as the Switch may be assigned to any one of the four after being redirected by spring18:
These servers are present across failures and successes pointing towards this being a backend timing issue, and not a server health issue as they wouldn't work at all if there was a health issue. They just need more time than our connections give them to handle the authentication/session creation correctly.
In my experience with this error, the manipulation of the speed of the network proved to be the only fully reliable way to avoid the issue. Outside of my recorded testing I had more success creating a session with my phone's hotspot, but like others, it still doesn't work some portion of the time because the speed of the network is variable, so without forcing it to be slower you're just gambling with better odds when using a hotspot...it seems like a fix but it is actually just masking the issue.
Please help get this information into the right hands, so we can get past this error once and for all.
Patient_Poetry you deserve a big pay check from EA for doing their QC/QA/test job. 😄
