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?

[JamesT91]

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.

[JamesT91]

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_Meraki_Device_Local_Status_Page/Configuring_the_Local_Status_Page

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.alfano - 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 @edazeved 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.

[Philip D'Ath]

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.

[Philip D'Ath]

This is a good use case for Meraki workflow automation.  Have a workflow run on a regular basis (such as every 90 days), generate a random password (leaving it in the workflow log), and push that out to every network.

https://documentation.meraki.com/Platform_Management/Workflows/Workflows