Local Status Page Password Changes for New Networks

[Mloraditch]

I can't find this in the documentation yet but it's clearly in the dashboard:

Appears that new networks created after 8/1/25 will have an auto generated LSP password that will push to devices on their first config download.

Can anyone from Meraki confirm my interpretation?

[PhilipDAth]

Wow.  That is certainly a change.

[BlakeRichardson]

It still amazes me this stuff like this just appears, surely each product team have someone who's job it is to update the documentation. 

[EAzevedo]

Hello!

This change (Local Status Page (LSP) mandatory password feature) was developed to enforce EU RED (Radio Equipment Directive) compliance.

It requires networks created after August 1, 2025 to have mandatory passwords set for Local Status Page access. It prevents the use of device serial numbers as passwords, which is considered non-compliant under EU RED regulations. The auto-generated password acts as a soft block to the Local Status Page, prompting users to set their own password as required under EU RED.

The public documentation will be updated shortly.

[Tony-Sydney-AU · Accepted solution]

Hello everyone!

Thanks for bringing this up, @Mloraditch and @BlakeRichardson .

Here's the updated document, fresh out of the press!

Shout out to @Hannah-C and the relentless people from Documentation Team!

[jimmyt234]

But when are we going to be able to actually view the passwords in dashboard again? This has been broken for months.

[RWelch]

I don't get the idea or impression it is coming back (could be wrong).  I gather the way forward is to set or in some cases, enter a new password if not done so already. 

Seems like it's set this way by design - hence even support does not have access to the password.

[SteMeDi]

I understand the EU policy, but I can’t comprehend why it’s not possible to view the password set in the dashboard afterwards. Do you know of any cloud tool that can set and securely manage LSP passwords via API? How do large customers handle this with hundreds of devices?

[Mloraditch]

I have to imagine part of the theory is, if you are in a situation where you have to access the device via the local status and it's offline, you can just factory reset it and if it's online you can just change it.

The inconvenience is slight for the situations where it's necessary. I'm sure there are corner cases but I have to guess that's the line of thinking

[SteMeDi]

The reset deletes the Support Data Bundle, which in most cases is requested by Meraki Support when a device is down on our side. The new handling of the LSP creates a huge workload for me and I expect Meraki to make the password visible in the dashboard again.

[SteMeDi]

I understand the EU policy, but I can’t comprehend why it’s not possible to view the password set in the dashboard afterwards. Do you know of any cloud tool that can set and securely manage LSP passwords via API? How do large customers handle this with hundreds of devices?

[Tony-Sydney-AU]

Hi @SteMeDi ,

Yes, I feel your pain. I also miss that old feature.

However, I believe they made it that way to also avoid someone "shoulder surfing" when you're checking or even eavesdropping. Imagine an employee that checks it and then leaves the company; now potentially this person has the ability to login locally if they leave the company and the other admins forget to change the local password. See the problem?

It's very common to have admins forgetting to rotate key / sensitive network passwords when someone leaves the company.

In that sense, your password management over API is a nice solution. I checked Cisco Meraki marketplace but couldn't find one.

Perhaps the best way to move ahead is for you to leverage a corporate password manager. There are plenty of options out there. E.g.: Proton password , Bitwarden , Keeper...

Hope this helps.

[jimmyt234]

You make it sound like it has definitely been removed from the GUI on purpose? I have a support ticket open where they are still "trying to fix it" ... am I being lead down a dead-end path here?🤔

[SteMeDi]

Support told me this:
Unfortunately the behavior with the new implementation changed and it is not possible to view the existing password in Dashboard. You can have more details in the document below: https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Me...

[jimmyt234]

Sigh ... what's my support guy trying to fix then? 🤣 I will ask them now and see if they give me the same response. Not sure why there is so much smoke and mirrors around it all - if you are removing a feature from the dashboard just come out and say it.

[jimmyt234]

I have now had a similar update from support, that we will never be able to view the passwords in the GUI again.

Hello

Following up on this case, to ensure the highest level of security and meet evolving regulatory requirements, neither Meraki nor the customers can see the password.

The network settings page will no longer have the ability to display a network’s LSP password.

It will be on the customer to save their password in a separate secure location for future reference.

The goal (and EU RED requirement) is for the customer to go and set it themselves. The intent of the auto-generated password is to act as a soft-block to customers to set their passwords themselves the first time.

Please check the document in the link below for more information.

https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Me...

Please let me know if you have further questions.

Kinds Regards

[Mr_Meraki]

Tony,

It sounds like there are 2 scenarios I am concerned about:

1) Device is online.  You can choose to set a password and then track that with some kind of password manager or spreadsheet.  Or you could just reset the password every time and don't bother tracking it.  Is that accurate?

2) The second situation is the device is offline but a password has been set.  Are you saying a reset wipes the password?  Just thinking of situation where the device has been statically set so you can't get it back online.

Thanks in advance.

[Tony-Sydney-AU]

Hi @Mr_Meraki , these two scenarios are valid concerns and they can be addressed as follows.

1. Device is offline; you setup a password and manage it with your own solution. Here, the device will synchronise with dashboard and apply that local password once it goes online. After that, you will use the local password you defined in dashboard and stored in your own solution. You may define it every time you need local access; nothing prevents you from doing that. However, the only time you need local access is when you are doing a basic config to make it connect to dashboard or some troubleshooting. Therefore, it's not best practice to change it every time as the consequence is two fold: [a] device might be offline so it doesn't get the new password, [b] new password applies to all devices so you would need to know it when you troubleshoot a different device. So this last fold brings us to your second scenario
2. Device is offline but a password has been set and nobody knows it; so here a factory reset would erase it along with any other config. As a result, you would login locally with serial number and configure it to be online in dashboard. Once device is online, it would sync with dashboard and get the new local password again. Therefore, if you don't know the last password, you'll have to redefine it every time you do maintenance or add a new device. That's what I call administrative overhead and definitely not a best practice.

In summary, We can think of a "situation where the device has been statically set so you can't get it back online." and that's the case where a factory reset is useful. For example, a config that brings the device offline, like adding the wrong management VLAN. You can bring it back after factory reset but the device would synch with dashboard and put the wrong management VLAN again. The result is a kind of a racing condition where you need to know the local password and also revert the change in dashboard. Otherwise you may get an offline and online loop situation.

[Mr_Meraki]

@Tony - What in your mind is best practice in handling this change for an MSSP with 100s of service desk agents managing a Meraki dashboard with 100s of orgs, thousands of networks, and tens of thousands of devices?

[Tony-Sydney-AU]

If I were to manage such MSP, I would seriously evaluate a corporate password manager. Assuming MSP has it's own Directory Service (MS Active Directory or any other), it's key that the password manager solution accepts logins from your Directory Service. This would allow you to disable just one login in case an employee leaves MSP.

For extra security, you may rotate device's local password by using API calls in all managed orgs. 😄 Don't ask me exactly how to do it. I just know that this API exists.

[Mr_Meraki]

Thanks Tony!  Unfortunately that is not a great solution.  Even if you wanted to spend the money to do that, you have to make sure 100s of agents across the globe are using it correctly.  It is just not feasible.  Unfortunate that Meraki is doing things that nobody wants.  

[Tony-Sydney-AU]

Hi, @Mr_Meraki ,

It's a hard reality in computing: you add complexity every time you tighten security.

As you know from @EAzevedo reply, this change was made to comply with EU RED standard.

I'll say it again and you can see it in my earlier reply "I feel your pain. I also miss that old feature". I'm not just saying.

I'd better stop here before I start getting off topic while I runt about the good old days... And then someone will post that meme "Old man yells at cloud" making fun of me.

Anyhow, I'm not trying to convince you that the new local password feature is good or using a centralised password management solution is a great solution.

I'm here to help, just like you. Those are my insights on how We can adapt to that new regulation. The dashboard can change if enough people make feature request and We find a way to still comply with EU RED.

Thanks for your insights and thanks for understanding, @Mr_Meraki .

[Mloraditch]

@Mr_Meraki  I'm really curious how often are you accessing the local status page (to the point where you have to login) and what are the use cases besides initial setup (no password set yet) or outage recovery (factory reset adds maybe a couple of minutes to the process IF you don't know the password)?

I manage ~100 orgs with over 1000 MXs and 7000 MR/MS and I can think of very few cases where we access these past initial setup.

[PhilipDAth]

I just had an interesting idea.

It wouldn't be hard to write a script to configure a random local status page password for each network.

The question then becomes, where to store it?  What about creating a group policy called "local-status-page", and saving the password in a dummy firewall description field?

Or use one passwod for the whole org, and store it in the "MSP ID" field under organisation settings.

Or perhaps add it as a network tag under Organisation/Overview.

[Mloraditch]

The only downsides to those are your RO admins could see the info, but if you are small enough to not have any background api tools where you could add password management and your password system not have an API where you could easily keep things in sync, that is less likely to matter, certainly seems like a usable workaround. Run your script 1x a week or similar.