I setup the DGX spark and while trying to give the wider team access to it, started hardening it by setting up the UEFI password and now have forgotten the password. On power on the DGX Spark displays a password screen even before loading the OS. Cant get further than that. I have raised a ticket “DGX Spark - Account Pw reset Query [Incident: 261011-000673]” who advised me to post the query here.
Can someone help please? I need to take it to the GTC Event on 20th of October.
For details about the system:
DGX Spark GB 10, 128 GB DDR5x Unified RAM, 4TB
Purchased on 26th August, 2026
Please let me know if someone has faced this and is there way to reset it even before I return it back.
I have tried the recovery disc, it does not apply here are this does not reach that stage at all. I am stuck at the UEFI password screen itself.
Sorry you’re in this spot - and ignore the “brick” doom a bit, there’s a real
path here. Two parts: getting the password back out of your own head, and, if
that fails, the fix that actually works before the 20th.
First, try to rebuild the moment (giles8’s hypnosis joke, done for real)
A password you typed once lives on context, not willpower. Staring at the
prompt won’t surface it — rebuilding the scene around when you set it often
will. You set this during a “harden it for the wider team” pass right after
unboxing, so walk back into that session:
Mindset. You were in security/provisioning mode, probably following a
checklist or your org’s standard. The UEFI password you chose is very often the org’s standard pattern or a variation of it — not a one-off.
The scene. Desk or lab bench? Morning-coffee setup or a late push? What
else was on screen — a runbook, a wiki page, the ticket? Were you on a call
or screen-sharing with someone while you did it? What were you listening to?
The incidental stuff (track, podcast, who walked past) is a surprisingly good
thread to pull.
Your hands. UEFI makes you enter it twice (set + confirm), so there’s
muscle memory. Let your fingers try the patterns you reach for without
thinking.
Reuse within the session. That same sitting, did you put the same
string on anything else — disk/OPAL password, BMC, the OS login, a test
account? People reuse inside a single setup pass. If any of those is still
reachable, it may be the same secret.
The big one — you were provisioning for a team, so you may have recorded
it. Check your password manager (search by date created around your
setup day), a shared vault, an onboarding/“DGX setup” doc, a screenshot, a
note-to-self, even the support ticket. A hardening step is exactly the kind
of thing people write down.
If it won’t come back: RMA is the real answer
Being straight with you: the UEFI admin password is enforced by the platform
firmware before anything bootable runs — that’s why your recovery disc never
gets a turn. On a sealed appliance there’s no jumper or coin-cell to clear it,
and the password you set isn’t inside any downloadable firmware image; it’s in
the unit’s own NVRAM. So the dependable fix is a hardware one. Go back to your
ticket and ask explicitly for an RMA / depot service for a firmware-level
password lockout (not forum triage), and given the GTC date, ask about an advance / cross-ship replacement. That’s the route that actually puts a
working unit in your hands.
What the password is, and the one non-destructive DIY attempt
For the curious, here’s the shape of it:
It’s an AMI Aptio V setup/admin password, stored as a hash in NVRAM
and checked by the firmware’s secure side. It’s pre-OS and hashed — not
sitting in plaintext anywhere you can reach from a booted system.
Reassuring part if you want to try guessing: there’s no permanent
“too many attempts = bricked” lockout on this password — it isn’t tied to
the TPM’s anti-hammering. You get a few tries (AMI’s default is ~3 but not measured on the spark) per boot,
then it halts and you power-cycle; the counter resets each boot. Repeated
attempts won’t make things worse.
The only non-destructive way to automate that is a KVM-over-IP (PiKVM,
JetKVM, or GL.iNet’s Comet): it sits on the HDMI + USB and presents as a
keyboard, so it can type at the BIOS prompt, and you drive it remotely. Add a
smart plug (or the KVM’s own power control) for the power-cycle, and a short
script: type a guess → Enter → read the screen → on halt, cycle power → next
guess.
Is it worth it? The Spark is back at the prompt in a second or two, but
you’re still capped at the number of guesses per power-cycle — a few attempts every
several seconds. That’s plenty to exhaust a 4–6 digit PIN (hours to a couple
of weeks) or a small wordlist of passwords you think you might have
used. It is nowhere near enough for a real, high-entropy password — that’s
effectively never. So only reach for the KVM if you’re fairly sure you set
something short or guessable. If it was a proper password, don’t burn the
week — RMA.
Good luck — I’d genuinely start with the password manager’s “created on that
day” search and the reuse angle; those two shake loose more forgotten BIOS
passwords than anything else.
P.S… I looked through teardown images of the Sparks and didn’t notice any obvious buttons or headers for performing a reset.
Thank you Christopher! Really appreciate it. I will give those a go. I am in bit of spot of bother here due to the timing (as always is the case). Trying password for over 2 days now.
Well, tried the RMA process and seems I am now left with an expensive brick that I cannot use. Tried all possible combinations of passwords over the past 2 weeks (2 hours everyday with weekend specials as more hours) no luck. I am sure I have used all the passwords I have ever created in my entire life. How do I rule out it is not a firmware problem, I might be typing the correct password from the beginning?
Well learning is, dont tell NVIDIA that you set the password. It means they dont replace it. Needless to say, absolutely disappointed.
So where do I take it, as I have found the NVIDIA support team who the case was escalated to unhelpful in resolving the issue. Is there somewhere I can pay and get it fixed please? Missed the GTC and possibly going to miss 2 more events where we wanted to demo it.
:) it is not working it seems. Any ideas about what else can I use to run a 70B parameter model locally apart from DGX Spark. We are building an appliance which will have OpenSource solutions for our clients for repetative processes that can run on local models (privacy and predictable cost) trained on the client data with no need for frontier model access. I believe this NVIDIA process is going to take long and I am a little worried about banking on NVIDIA’s to support overall. Also, what do you guys use to ensure ongoing support that is useful.
You are correct. Seems interesting though. First purchase over a grand (5K+ to be precise) where there is no way forward. Or is there anywhere I can take it and pay to fix it.
AMD seems a cheaper option at the moment and should run the inference at a similar speed. And of course will face the same issue if you attempt to set the user bios UEFI password and forgot the password.
Currently, ballpark , it’s about 60% price of Nvidia Spark. With ram speed being the main bottleneck, it should serve at a similar speed to Spark. Main disadvantage is obviously the CUDA moat, and it’s more “shared” memory than unified memory regardless of what the marketing said. But if all you really want to do is to “serve” the weight already quantized by someone else, it works fine for the common use-cases. Minisforum is probably one of the better known ones for a balance between price and quality but every PC manufacturer has a model. Talk to your favorite vendor. Further discussion is probably outside the scope of this board.
I wouldn’t bank on support from NVIDIA for your issue, it is the same as throwing coffee over it and expecting warranty. Maybe check you home / business insurance for accidental damage protection, not a warranty isssue.
Don’t ask for alternative non NVIDIA solutions for this situation on an NVIDIA forum, really bad form.
Agree. They have been super unhelpful. I do have a business insurance. I will try that. Well asking for alternatives is purely to get advice from someone who has been through similar thing. I dont believe it is bad form, as I am just looking for solutions and next steps. 5K is a good amount for most people and having to see it go down the drain, one would try and see what alternatives are available and take the learnings.
Thank JW2026 for the advice and a very professional response and being helpful. Appreciate it. Agree the vendor discussion is outside the scope of this forum.
Also, it is not like throwing a coffee and expecting warranty to cover it. One is 5 quid and other is 5K for starters, one is anyone can make it at home without a problem, other is only NVIDIA knows or has the tools to access it. I cant even confirm now if I have already typed a correct password and it has worked. It never worked not even once since I setup the password. And many more things. But be helpful if you can (as you have done for some part) else let me sulk on my own, you dont have to add to the misery, just cut the later part out of your comments and you will be golden. Dont pass judgements like dont ask alternative solutions, let me do my thing, you sit and enjoy the spectacle.
If this resonates with someone I might get a credible solution how they got out of the situation. Anyway, have a great day!
Since this is a feature intended to keep unwanted parties from being able to use the device at all, it’s relatively expected that there is no (published) way around it except to know the password. There would be no documented method or (published) tools to reset it as that would defeat the purpose of the feature.
I do think it’s a shame that NVIDIA wouldn’t offer some kind of service, even if paid, so long as you could provide proof that you are the original purchaser of the device.
If I were in your shoes I would be more persistent with Nvidia. I think it’s insane that they directed you to the user forums to look for a solution to this, when it is Nvidia and only Nvidia that would know if this is something that can be reversed at all, let alone have access to the tools to do so.
I’d keep pestering nvidia and explain that you are willing to pay a fee if you can have the device sent in for a full factory reset.
If you ever give up and want to sell it to get some money back I’ll buy it at a price that reflects that it may just be a paperweight from this point out.
Unless it has D@RE, users passwords on bios are kind of silly. And yes, I agree that Nvidia (and OEM partners as well) needs to do much better with support.
Well that is what I was expecting to be honest. But it is too big a company now (large data centers etc. making over 70% of its revenue from top 5 customers,), for the consumer bit like this to be of any consequence. I am going to exhaust all my options with them, right from consumer court to ombudsman etc. as it seems fundamentally flawed, though as you have stated it is a safety thing, it is one of those things which is in that assess on a case by case basis. I have provided all the documents of purchase etc. But thank you for a constructive message. Appreciate it.
Does not pay to be honest it seems, must have just said I dont know what happened on second thoughts, which is fundamentally wrong though.