Key Points
- NinjaOne 16.0 expands Browser Management with unified browser configuration, letting admins set a much broader range of browser behavior in a single policy.
- New controls cover startup pages and homepages, bookmarks, HTTPS enforcement, password, payment, and cookie storage, browser notifications, and browser AI agent settings.
- One policy can standardize startup pages and bookmarks across the organization, which helps onboarding, reduces “where’s that link” tickets, and lets MSPs reuse a standard configuration across clients.
- Admins can enforce no saved passwords, no stored payment info, and HTTPS everywhere, giving consistent settings and a clear answer for compliance and audit questions.
- AI agent controls sit in the same policy as other browser settings, so teams can set rules for new built-in browser AI features without a separate project.
- Browser configuration lives alongside patching and device management in NinjaOne, with no new console, agent, or policy system.
Ask any IT admin how many times they’ve been asked to “just make everyone’s browser open to the intranet.” Now ask how many of those requests turned into a GPO, a script, a sticky note, or a lot of walking around. Browser settings are small individually, but they add up fast. And a few of them (saved passwords, stored payment info, cookies) are not small at all from a security standpoint.
That’s the thinking behind the expanded browser policy configuration in NinjaOne 16.0. If you already use Browser Management for extension visibility and website blocking, this release adds a broader set of settings you can control from the same place.
Why browser settings are harder than they should be
Endpoint management got good at the OS a long time ago. Patching, configurations, and remote access are all pretty well solved. The browser, where people actually spend their day, has mostly been left to defaults, user preference, and whatever a past admin managed to script.
The result is drift. One person has a different homepage, another saved their card number in Chrome, a third has notifications turned on for a site they visited once in 2022. None of it looks like a big deal until an auditor asks you to prove how browsers are configured, or until something goes wrong and you realize nobody ever set a baseline.
See the browser security gap
New in 16.0: Unified browser configuration
Admins can now set a much broader range of browser behavior in one policy. This includes:
- Startup pages and homepages: Decide what opens when the browser launches and where the home button goes.
- Bookmarks: Control bookmark toolbar behavior, pin bookmarks, and push custom bookmark lists to users.
- HTTPS enforcement: Require secure connections instead of hoping users notice the padlock.
- Password, payment, and cookie storage: Set policy on whether the browser can save passwords, store payment info, and keep cookies.
- Browser notifications: Manage whether sites can prompt users with notifications.
- Browser AI agent controls: Set policy for the AI agent features that are beginning to be shipped with browsers .
Taken together, it’s a much more complete toolbox for standardizing and locking down the browser experience.
Use case 1: Same tools, same bookmarks, everywhere
Previously, if you wanted every employee’s browser to open to the same internal tools with the same pinned bookmarks, you had to touch each machine or maintain scripts that break when a browser updates. With unified browser configuration, you build one policy that sets the startup pages, the homepage, and the bookmarks, then push it across the organization.
While this may sound minor, it helps onboarding (new hires open their browser and everything is already there), cuts down on “where do I find that link” tickets, and puts the right resources in front of people by default. MSPs can build a standard configuration once and apply it to client after client instead of rebuilding it every time.
Use case 2: Locking it down for compliance
Let’s talk about the security side of browser policy configurations. A security focused organization might need no saved passwords, no stored payment info, and enforce HTTPS everywhere. Those are common asks in compliance conversations. They’re easy to say, but difficult to prove.
The admin sets the policy once through unified browser configuration and it applies consistently across every managed device. The same rules on every machine, no exceptions based on who set up their laptop. That also gives you a clean answer when someone asks how browser credential and payment storage is handled.
Uncover hidden browser risks
The AI agent piece matters more than it seems
Browsers are adding built in AI agents, and they’re showing up faster than most policies can keep up. Having a control for them in the same policy as your other browser settings means you don’t have to wait for a separate project to decide what’s allowed. You can make a call, set it, and adjust later. It’s early days for this stuff, but the teams that get a handle on it now will have fewer surprises later.
One place, not five
The bigger point is where this capability lives. Browser configuration, extension controls, and website blocking now sit alongside patching, device management, and the rest of what your team already does in NinjaOne. No new console, no separate agent, and no second policy system to keep in sync. Fewer tools means fewer gaps.
What’s next: Katana AI and your browser data
Katana AI, NinjaOne’s agentic AI assistant, is currently in Early Access and already works with browser management data. You can ask it which extensions are installed across your environment, check the risk profile of a specific extension, or look at which domains people have been visiting over the last seven days. Taking policy actions through Katana AI isn’t available yet, so for now you’ll set the configurations above in the NinjaOne console. Getting started
If you’re already using NinjaOne Browser Management, the new settings are available in 16.0 so you can start building policies today. A good first move is to pick one baseline that matters to you (HTTPS enforcement and password storage are easy wins) and roll it out to a pilot group. Once you see it work, expand from there.
Not using NinjaOne Browser Management yet?
