I would like to know more details about the Change Owner feature. Are there safeguards around this? It would be ideal to have a notification go to the current account owner who would then approve the change.

Also, under Subscription, is it correct to assume that the "Yes, cancel my account" button is only accessible when viewing as the account owner?

@Christoph - The options for authentication will not change. This means you can set up JWT, SAML, Google, or Microsoft authentication for agents, and any of those plus Twitter and Facebook authentication for end-users, just like today. Note that JWT and SAML authentication are plan limited.

Will we ever have a separation of privilege? ie. the Account owner is not necessarily an admin? That way we can make the payments go to like an "Accounts Department" but we don't need to consume a licence as an "Admin" given that the accounts department won't really need to use Zendesk and change overall settings?

Now that I've had a chance to look at the new admin experience, specifically the Security section, I have a couple of questions:

SSO bypass - this used to be a checkbox to allow specifically admins to request a one-time sign-in link. Now, that checkbox is gone, and there is simply messaging that "selected users will be able to request a one-time sign-in link". It is inappropriate for security features to be vague about who it applies to. It's also not cool to remove checkboxes without warning customers, especially if you're changing the default behaviour to checkbox=true. (Edit: Apparently a radio button is supposed to appear under session expiration, but we don't see in some instances. I'm raising a support ticket.)

Session expiration - this used to be exclusively tied to Zendesk passwords. It's now on a separate tab and we seem to be able to customize it even if Zendesk passwords are disabled. That's new. Is it still exclusively tied to Zendesk passwords? Or does it now apply to SSO as well? Hoping for the latter because that's been a security concern for customers for a long time. I recall commenting on multiple feedback posts about this in the past but can't locate them anymore.

EDIT: For the first question, I found out this setting only appears for the account owner. I don't really see the point of that. As an admin, I can turn Zendesk passwords back on for the entire instance, but I can't toggle whether admins should be able to use sso bypass?

SSO bypass. I can understand your concern here. In actuality, nothing has changed as far as the behavior goes. there are no new ways to set up your account's authentication, and there are no options lost. We've attempted to make the new UI clearer, but it may be confusing to anyone getting use to the change. So, in the previous UI, you could uncheck the box which would result in a similar message, and a drop down which allows you to select who can access the bypass option. That drop down is still available, and this is what's meant by "selected users". I can see that this is pretty unclear, so we need to update our messages here. You can find the drop down that allows you to select which users my bypass SSP on the Advanced tab of this menu.

As for why the setting can only be accessed by the owner, this is related to the fact that the bypass itself can be set to only allow the owner to use it. I'm not sure how important that is, so we'll look into it, but for the time being it is behaving as expected.

Session Expiration. This used to be set on the same window as custom passwords, yet. It was never literally tied to passwords, but was only available if you were using custom passwords. We've decided to open it up to anyone who has the correct plan type available, even if you use external auth or a less secure password type.

For SSO Bypass - I know it helps you guys out when we explain our use case. So here goes:

For us, and I suspect for a lot of other customers, it's the admin team who are responsible for security maintenance. The account owner is typically a higher-level executive who manages subscriptions, but rarely actually logs in to Zendesk. If there are security changes that need to be made, or if an SSO outage happened and the bypass actually needed to be used, it's the admin's job to deal with it.

I appreciate that there is a toggle, and I can certainly check with our account owner to make sure it's toggled on for both owner and admin. But it's my job as an admin to manage the security settings, and it doesn't feel right to have to bother the account owner who rarely logs into Zendesk.

Thanks for the clarification about session expiration! If I'm interpreting correctly, what you're saying is: session expiration does still apply when using SSO. If that's true, I'd love to see an official Announcement post about it - you guys should be shouting it from the rooftops! That's a huge win and a significant security improvement.

Thanks, Stephen. I think we definitely need to improve the granularity of our agent permissions -- in fact it's something we're thinking about now. These default permissions that cannot be altered just don't scale with all the use cases we're seeing. This is definitely something we'll look at.

The thing about session expiry is that it has always affected SSO as well. It's always been set to a default of 8 hours. We'll look into making sure documentation is properly up-to-date.

If we want to disable Zendesk passwords for end-users, and enforce SSO, this message pops up:

Even though I'm on the End-users tab, it only mentions "staff members" being unable to sign in. And then, once that's saved, there's messaging that end-users can always sign in via mydomain.zendesk.com/access/normal:

I can confirm that we use two different SSO providers for End Users and Agents. Although we do have to set one as the primary. In this case, it has to be the end user one and you would need to ensure there is a link to the agent portal on that login page.

It's a bit of a pain an unauthenticated agent is always be sent to the end user login page when clicking on ticket URLs, but once logged in all the agent bound links work as expected.

@Stephen it looks like you can disable the native authentication for end-users as well. The pop-up your seeing is displaying the incorrect role but should still work. I've made our internal team aware of this and they are currently looking to get this pop-up updated.

One of our biggest pains is managing licences, some native tool that would help us with this would be very very welcome.

Especially when managing hundreds of users, and restricted by a max. number of licences we can distribute across all our operations, it's quite difficult to search for potential inactive users, in order to review and try to give those licences to other teams who want to join the Zendesk experience.