What has changed in Sign In, newest first.
Bug fixes and routine maintenance are not listed here. The platform release notes cover every service in one feed.
New
Under Self-Service Portal, Teams an organization keeps teams of email addresses, added by hand or provisioned over SCIM. A team is bound to a Sign In access policy, to an EasyPSK, EntryPoint or Endpoint Manager group with the roles its members get, to an EasyPSK onboarding rule or to a Site manager role. A binding can send a welcome mail to people who join later.
New
A new Self-Service Portal runs beside the classic one. The organization chooses the Default portal, Classic unless changed, and each user can switch. An EasyPSK group opens on a home page with the network, the password, the QR code, the devices with online state, the device cap and Register a device for Wi-Fi or cable. Sign In, EntryPoint, EasyPSK and Endpoint Manager groups all have pages there.
Improved
In the new Self-Service Portal a conference host downloads the answers attendees gave at sign-in as a PDF, or mails the PDF to their own address, beside the CSV export. A conference’s details list the latest answers and participants, with Show all.
Changed
Netgraph can pause a RADIUS service that receives no authentication or accounting requests. Its settings are kept, and its network settings show RADIUS service paused with the date requests stopped. Start service makes it accept requests again within a few minutes. This applies to EntryPoint, EasyPSK and RADIUS Proxy services and to MAC authentication for Sign In on Cisco Meraki.
Improved
The audit log of the organization and of each Sign In, EntryPoint, EasyPSK and Endpoint Manager service is a timeline with search, a period, chips per kind of change with counts, and a panel showing each change before and after. Export CSV downloads the newest 5,000 entries.
New
An Applications entry under Admin Access Control, in the Admin Console and in the MSP Portal, holds API keys for scripts and integrations. A key gets the APIs it may call at Read or Write level, the Sign In contexts it covers (all, including new ones, or a selection), a token expiry from 30 days to none, and an IP access list. The token is shown once; a key can be disabled and rotated with an overlap of up to seven days.
The Alerts page warns 30 days before a key’s last token expires and when it has expired, with a link to the key.
New
The Applications page shows the API base URL and every endpoint path with the organization, context and partner IDs filled in. With the Platform API an organization key reads the organization and its contexts and manages Sign In access policies, their email patterns and whitelistings, with batch create and revoke. With the MSP API a partner key reads the status of every tenant’s Sign In contexts: each Service Gateway router’s reachability and SXP connection, and the default gateways of the DHCP scopes, filterable on state.
Lists are paged with a cursor, errors carry one code per cause, and an OpenAPI description is served at /openapi.json under the base URL.
Changed
Under Configuration, Common Settings, a Sign In context with the per-context API key turned on keeps it, can replace the key and can turn it off, and once off it cannot be turned on again. A context without it shows an API access card that points to the organization’s API keys under Applications, which new integrations use.
New
The Policies page in the Cloud DNS section can check one domain against every policy in the context at once. Each policy answers whether the name is blocked, whether the name itself or a parent domain is listed, and which category or list of your own carries the entry. It also says when an allowlist entry does not cover the name because the block comes from a parent domain, and what to do about it. The lookup replaces the download of a policy’s effective list, which could not say which list caused a block.
New
A Statistics page opens the Cloud DNS section. It shows how many DNS queries the network answered and how many a policy blocked, as three figures and a trend for today, the last 7 or 30 days, or the last 6 or 12 months. Usage is sampled every few minutes and counted per network. The page follows the roles that read the context’s other statistics, so it can be followed without the right to change the filtering.
Changed
An entry in a blocklist of your own covers the domain and everything under it, so no wildcard is needed; a typed wildcard prefix or trailing dot is accepted and dropped, and an entry that cannot be a domain name is refused. An allowlist entry removes exactly the name it holds from what a policy blocks. The category catalogue lists the active categories only; a category the platform has switched off stays, marked inactive, in the policies that already selected it. Two categories are recommended, Malware, Phishing & C2 and Scam & Fake Shops. A policy holds at most 50 categories, 50 lists of each kind, and five million domains in total.
New
Cloud DNS now ships a catalogue of blocklists that Netgraph curates and keeps current, in three groups: Security, Content, and Ads and tracking. A category states what it covers and what it does not, its domain count and when it was last updated. Three categories are marked as recommended, and a context with no policy yet can start from them in one step. The catalogue is included in the add-on.
Changed
A context in Cloud DNS mode gets its own section in the menu, with three pages: Policies, Lists (Categories, Blocklists and Allowlists) and DNS settings (forwarding and internal DNS records). The DNS tab under Service Gateway now holds only the DNS mode switch. Rulesets are now called policies, and the editor is its own page: name, where it applies, when it applies on a week calendar with presets and a time zone, what it blocks, and what it always allows. Each policy card shows its status, what it blocks and allows, and how many domains that is, and can be duplicated.
Improved
The pages reached from email links (sign-in confirmation, meeting host requests, sponsored device requests) are rebuilt as full pages in the portal look, with explicit approved, denied, revoked and not enabled states. A guest at the device limit picks the device to log out on the page, and each page renders in the language of the email it was opened from, offering only the languages enabled for the portal.
New
A Sign In Enterprise network can be turned from plain DNS forwarding into a managed filtering resolver that Netgraph runs for it. Every lookup is checked against the policy you set before it is answered: blocked domains do not resolve, allowlisted domains always do.
You subscribe to blocklists by URL, which are fetched and kept refreshed for you, or build your own. Allowlists always override blocklists, and custom records map internal names to addresses.
A ruleset combines the lists, an audience of either the whole network or selected sites, and an optional weekly schedule with its own time zone, so a policy can apply only at certain hours.
Lists and records can be imported and exported in bulk, and the fetch status of a subscribed list shows when it was last refreshed.
New
DHCP scopes can be uploaded as a batch instead of created one at a time, and the scope selector stays usable when a gateway carries a large number of them.
Improved
A context can export its whitelistings, and the import file accepts an optional end date column, so an entry can be given an expiry when it is created rather than afterwards.
Changed
The card was headed "Logins Today", which read as logins since midnight. It has always counted a rolling 24 hour window, and the heading now says so. The number itself is unchanged, but a report built on the old wording was measuring something else than it claimed.
New
The portal's colours and imagery can be drawn from a website address instead of being set by hand, and the address is prefilled from the organization's own website when one is recorded.
New
A Service Gateway is configured from a framework template rather than field by field. The template carries variables, and the console shows which ones are unresolved and which custom variables are defined but never used, so a template can be checked before it is applied.
A template with unresolved variables cannot be downloaded, which is what previously produced a gateway configuration that looked complete and was not.
Creating a gateway also asks for less: IP and BGP settings are no longer required and fall back to defaults, and framework and BGP settings are edited in place instead of through separate dialogs.
Available to organization administrators and, for partners, in the MSP Portal.
New
A site can define the address a guest is sent to once they are online, so the portal can hand over to a venue page or a booking system instead of the page the guest first tried to reach.
New
The email self-registration form can carry extra fields that you define, so a guest can be asked for what the venue actually needs, such as a room number, a company or a reason for the visit.
New
Quick Access, the one-click sign-in that asks a guest for nothing, can be given a limit on how many connections it admits, so an open network can be capped without switching to a login module that asks for an identity.
New
Each DHCP scope on a Service Gateway decides for itself whether it hands out Option 114, the captive-portal address that lets a device open the portal on its own instead of waiting for a redirect. The scope list shows the policy per scope.
New
An organization can federate sign-in against its own identity provider on all three surfaces: the administration portal, the Self-Service portal, and the captive portal where a guest or employee signs in to the network.
Each surface is configured separately, so an organization can federate its administrators without federating its guests, or the other way around.
New
The people on a Password module subscription list are emailed when a new password takes effect, so reception staff and hosts do not have to look it up. The notification can also be sent again on request.
New
A context can be divided into sites, and an access policy can defer its redirect to the address configured for the site the guest is actually at. One policy then sends guests to different places depending on where they connected.
New
How long login records, session history and device data are kept is set per service context, under Administration and Compliance. The shortest period that can be configured is one day.
Terms and privacy policy are handled separately from each other at the same time, so one can be changed without touching the other.
Improved
The RADIUS settings a Cisco Meraki network needs for MAC-based authentication and for the splash page are presented together, so the values to enter in the Meraki dashboard can be read off in one place.
New
DHCP activity is recorded and can be downloaded, and the lease history for a single device is shown on that device in the console, so an address can be traced back to the equipment that held it.
No entries for that service yet.
