A lot of stuff on VAG was key = seed + constant.
If it's not, then you're gonna have to reverse the $27 service handler and find out what the algo is.
The explanation of the service table and how to find it can be found in my KWP2000 logging repo.

Different security access is for different services and sessions, I have no clue where you got that 0x03 is some "read only access", that's BS.

Also, for me development session on Mk4 VR6 worked without any security access.
When you connect to the ECU you are already in a diagnostic session. The default session.
You're gonna have to be a ton more specific.

At some point in time you are going to have to start to use your brain, and not throw your hands up in the air, and lose your head the moment CTRL+C, CTRL+V stops working

It's for MED9. You have ME7.

3 options:
1. OEM documentation
2. Reversing the comms stack
3. Trial and error.

I never did flashing or looked into it, so I have no idea if ME7 also has SA2 or not.
Could well be, then just grab an SA2 implementation (for example bri3d has one in his repo) and then use that.
There was also one in C posted.
Then grab the algo from an sgo.

Usually ECU's don't need SA2 to read memory though, at least the later ones.

Switch to the correct session. In which session are you trying it?

Security access was 03 with key 0x11223344?

Workaround for RMBA is DDLI ($2C), you can define up to 10 identifiers.
If you need to read more, you can clear, define, read. 3x slower if the identifiers can only hold 1 location.

The dynamically definable identifiers are from F0 to F9 on Bosch KWP2000 ECU's.
For DDLI syntax look at KWP2000 service layer standard.

You did not answer which SA you used btw.
Also you have never posted the file either. Use my repo to see where the service lookup table is and see if the ECU even has $23.

You're asking for help but it's like using a crowbar to pry information from you.
Every single question I ask is relevant. You answer only some, not all and you do not provide the basic info.
So I'm about to give up here.

I'm using SA Level 1.  I get a positive response when bitshifting:
  for (byte i = 0; i < 5; i++) {
    if ((seed & 0x80000000) == 0x80000000) {                 // can’t check the bit overflow / carry bit directly, but if the MSB is high then we can infer the next shift will set the carry bit
      seed = (seedData[63] ^ ((seed << 1) | (seed >> 31)));  // since C doesn’t have a rotate as such, OR the << and >> to make a rotate
    } else {
      seed = ((seed << 1) | (seed >> 31));
    }
  }

Where seedData[63] = 0x5FBD5DBD.  I'm struggling to get the ECU ID to calculate to this however.

I slow init, get a response, request security access (0x27 0x01), get the seed, calculate using the above and re-submit.  I then get a positive response and gain SA.

I then start a diagnostic session with:
    txBuf[0] = 0x03;  //Message Length
    txBuf[1] = 0x10;  //StartDiagnosticSession
    txBuf[2] = 0x86;  //Development Session
    txBuf[3] = 0x14;  // 10400 baud

Which is successful.  Attempting to RBMA fails (0x23...), as does write.  Hope that makes sense.