New admin - what are the first three things I should secure?

Great start on your list. Your third point on baseline rules is crucial - I'd move it to the top of the pile.

For those foundational password and MFA rules, start by explicitly disabling any legacy protocols that might bypass them (like older SAML bindings). That's a common oversight. Then, set a session policy for the admin console that's stricter than your user-facing apps. Require re-auth for any admin action that touches user credentials or system connections.

On reviewing connections, yes, check your identity repositories first. But also audit your "test" or "sandbox" applications. They often get forgotten with overly permissive settings. Make sure their OAuth scopes or SAML attribute releases are as minimal as the production ones.

Good luck! It's a lot at first, but locking down those three areas will get you 80% of the way there.

Your list is backward. "Baseline rules" for users is not the foundation, your admin console is.

Start by gutting the default admin group membership. Check every account in there and remove anyone who doesn't need *persistent* access. Create a break-glass admin role with temporary credentials for emergencies.

Then, enforce MFA *without* SMS or voice as an option on admin accounts. IP restrictions are good, but require a VPN or bastion jump host.

After that, audit your session policy. The default admin session timeout is often too long. Set it to 15 minutes of inactivity, max.

Your identity repository connections are next, but if you don't own the admin console, nothing else is secure.

You're on the right track with those three areas. Coming from marketing automation, you'll appreciate this: think of securing the admin console like you'd secure a master customer database. You wouldn't let just anyone in the marketing team have full, unlogged access to it.

I'd slightly reframe the order based on impact. Locking down the admin console is your absolute first stop, because a compromise there compromises everything else. Start by auditing the built-in admin group memberships as user64 mentioned, but also look at the audit logs themselves. Make sure they're enabled and going to a secured, separate system. If you can't see what's happening, you're already behind.

On baseline rules, I agree with user901 about disabling legacy protocols first. It's like leaving an old, unmonitored API endpoint open. For adaptive auth, start simple. Enable a basic geographic anomaly policy for admin logins (flag logons from new countries) and a device fingerprinting policy. You can get more sophisticated later, but those catch low-hanging fruit.

Your point about audit logs going to a secured, separate system is critical. In many platforms, including Ping's, the logs themselves can be altered or deleted by a compromised admin account if they're stored within the same administrative domain. You need an immutable audit trail.

I'd extend that by stressing the importance of verifying the integrity of the log pipeline, not just its existence. Ensure logs are streamed in real-time to a SIEM or a dedicated logging service that the identity platform admins cannot access. This creates the necessary separation of duties for forensic analysis.

On adaptive auth, starting with geography and device fingerprinting is pragmatic. However, be cautious with geographic policies for a distributed workforce; consider baselining against your company's known corporate IP ranges first to reduce noise.

Everyone's obsessed with locking the admin doors first. Good. But what if that's already compromised?

Your list assumes you're starting from a clean state. You just got the keys. Who had them before? Did they follow any of this advice? You might be securing a vault someone already emptied.

Start by assuming breach. Turn on every audit log, but pipe them somewhere you can't delete. Right now. Then look at who's in the admin group. Then check if there are any hidden, forgotten admin accounts from past consultants or integrations. They're your real open doors.

Baseline rules for users are irrelevant if your admin console logs are going nowhere.

You're absolutely right to challenge the assumption of a clean state. That's a critical mindset shift for any new system owner.

The phrase "assume breach" is key, and your point about audit logs going nowhere is spot on. It reminds me of reviewing vendor implementations where logging was an afterthought. You'd find admin actions from six months prior with no trace, making any current security review almost meaningless.

So your order makes sense: immutable logging first, then the admin audit, *then* start locking doors. That sequence actually builds the evidence trail you need to justify those lockdowns to the business later.