you guys are mistaking the edc15 "login" for the edc16 "security access"
these are separate and different functions and are NOT the same. They should not be mistaken for one another.
(though you could refer to the "login code" of 12233 as a password)
Just to be clear... there are NO manual adaptation channels in ECDC16 like they had in the older cars. Any required adaptations are done automatically by the ecu (also referred to as "ecu learning" by some). There are extra functions that are accessible through "basic settings" that act as "adaptations" of sorts, but you don't have the ability to manually change the value stored in the diagnostic section of memory (eeprom) as in ecd15. The ecu does it automatically through an internal programming routine.
However... there is a security layer or two acting as a gatekeeper for certain diagnostic routines- reading/writing the ecu being among these. (IOW flashing is included in the diagnostic routines of the ECU's internal programming "instructions" ) There's a command sequence sent by the user tool to access these diagnostic routines, whether it's to read/clear codes or identify the ecu, or read the flash or write the flash. To initialize these certain kinds of diagnostic session, the ecu responds to any request from the "tester tool" to initiate a session, with it's own "request" for a password. (login if you will) In EDC16, If the wrong password is supplied by the "tester tool", then the ecu refuses to start the diagnostic session, (response = 7F) with a reason code of "wrong password", and it's "strike one". (a "counter" increments +1) Try again with the wrong password, "strike two". After four failures, BAM, security lockout.
Once security lockout becomes active: Then EVEN IF you input the correct password, along the 7F ("session refused" A.K.A. "negative") response, you will get the "reason" for refusal of access = 37 = "requiredTimeDelayNotExpired". The response string is: 7F,27,37 where 7F is the response (negative), 27 is the request received (security access requested), and 37 is the reason (requiredTimeDelayNotExpired)
Q-loader will display this error as 01 02 which refers to where in the routine the error occurred (what step it happened at). Reading the device log will show the error string of 7F,27,37 (this info is encrypted and must be sent to us for interpretation)
In other words once the lockout is triggered, there is a time delay before further access attempts can be made (even with the proper password). This lockout begins at 20 minutes, then after another round of failed passwords the time doubles to 40 minutes, and so on, up to a maximum of 255 minutes.
To reset this kind of security lockout, leave the diagnostic interface connected and "handshaked", leave the ignition key on (car not running), with the door open, for the minimum required time. This resets the security access lockout. Usually 40 minutes does the trick. I suspect some companies like revo may just change the value that's stored in the eeprom to set the "required time" to 255 minutes as part of their flashing routine. This would serve as an effective way to "lock" the ecu from reading for most intents and purposes. The value is in the eeprom not the flash, so it won't affect the actual tuning being done, just prevent future access to that particular group of diagnostic routines. IOW a somewhat affective "read protection". (but not the only way...

)
Usually 40 minutes does the trick. But up to 4 hours 15 minutes may be required. Then the correct password can be entered to reset security access- and this password is 12233 if using VCDS (through the "security access" subroutine" or else simply using the flash tool (which inputs the correct access code automatically)
Hope this clears some things up