SQRL doesn't require a third party to authenticate with, so anything that mentions "our server", or cloud service, is using a third party to hold YOUR ID. Your SQRL ID is encrypted on the SQRL client. The two bits of information you are asked to "print/save" when you create the ID are your means to re-set/create YOUR ID. There is no third party who can help if you lose those two, it is you and only you who determines how and where you store them.
In the terms of secsign.com:
User enters his SecSignID (can be web service, ssh tunnel or OS login) and sends an authentication request to the SecSignID Server.
SQRL (simple version) - see https://www.grc.com/sqrl/crypto.htm for picture and more details.
1 User clicks on "login with SQRL" (on web server)
2. SQRL Client gets a request from the browser and requests the user to enter the password to unlock the SQRL ID
3. SQRL ID mashed with SQRL URL server from browser "sqrl://myservice.mycompany.co.uk" to generate new and unique (and repeatable) public and private keys and a signature of the whole URL using private key (the Authentication = public key and Identity = signed URL) are generated by SQRL client
4. SQRL Clientsends public key and crypto signature to web server
5. Web server uses public key to verify crypto signature (Identity and auth verified) - if OK -> logs in.
6. What the web server does with the public key after this, association with existing account or creation of new account is between the user and the server/service provider, is outside SQRL protocol.
Your encrypted ID NEVER leaves the SQRL client and no third party ever needs to store it. Where you save your ID and recovery code is your choice, but best kept offline (on paper) and put somewhere you know how to retrieve (safety deposit box, behind a family photo in a photo frame, dropbox) - from most secure to most likely and least secure.
(See SQRL essentials for more - technical - details)