IT access and enablement

Purpose. Everything a client IT or service-desk team needs to make Cura work for pilot users: the hostnames to allow, how to enable Microsoft or Google sign-in, and how to stop sign-in emails being quarantined. Cura is a standard web application. There is no software to install, no agent, no inbound connection to your network and no firewall rule needed in either direction beyond ordinary outbound HTTPS.

What you need to do

Contents

• Hostnames and network access

• Sign-in options

• Microsoft Entra ID

• Google Workspace

• Magic Link and email security scanners

• Email delivery

• Who can sign in

• Rolling out to your pilot group

• Media, live events and analytics

• Test and sign-off checklist

• Troubleshooting

• What Cura needs from you

---

Hostnames and network access

All traffic is outbound HTTPS on TCP 443. Nothing needs to reach into your network.

Two further requirements, both of which most environments already meet:

• First-party session cookies must be allowed for your Cura hostname. Cura sets HttpOnly, Secure, SameSite=Lax cookies. They are scoped to your workspace hostname only and are not shared with any other Cura tenant.

• JavaScript must be enabled. Fonts and styles are served from Cura's own domain, so no third-party font or CDN host is required.

Supported browsers: current and previous major versions of Edge, Chrome, Safari and Firefox. No plugins or extensions are used.

Search indexing: no action required. Every client-facing page returns a noindex, nofollow instruction, so your workspace cannot appear in search results.

---

Sign-in options

Cura is invitation-only and stores no passwords. There is no password field anywhere in the product, so there is nothing to reset, reuse or steal. Agree one or more of these routes for your pilot:

Magic Link works without any identity configuration, so it is the quickest route to a working pilot if approving an app will take time. It can be used alongside either OAuth route.

---

Microsoft Entra ID

Cura signs users in with a single multi-tenant app registration. Your organisation does not register anything; you approve Cura's app to operate in your tenant.

What the permission actually allows

User.Read is the minimum delegated Microsoft Graph permission. It lets Cura read the signed-in user's own basic profile, once, at the moment they sign in. Cura reads three things from it: display name, user principal name and email address.

• It is delegated, not application permission, so Cura can only ever act as the person signing in, and only while they are signing in.

• It grants no access to mail, files, calendars, Teams, directory data or other users.

• Cura does not request offline_access, so no refresh token is issued and Cura has no way to call Microsoft Graph later. Access tokens are used to read the profile during sign-in and are then discarded. No Microsoft token of any kind is stored by Cura.

Approving the app

Choose whichever of these fits your policy. Any one of them is sufficient.

1. Grant admin consent up front (recommended). In the Entra admin centre, open Identity > Applications > Enterprise applications, search the Application ID above, and grant tenant-wide admin consent. Your users then sign in with no consent prompt. If the app is not yet listed, an administrator can visit the Cura sign-in page once and consent on behalf of the organisation, which registers the enterprise app in your tenant.

2. Allow users to consent for themselves. If user consent for applications permits low-risk delegated permissions, each user approves the same User.Read request on their first sign-in and no admin action is needed.

3. Use the admin consent workflow. If user consent is disabled, the first user to sign in raises a request for an administrator to approve.

Conditional Access, MFA and assignment

• MFA and Conditional Access work normally. Authentication happens entirely on Microsoft's side, so your existing policies, including MFA, compliant-device and location conditions, apply to Cura sign-in without any change. Cura never sees a credential.

• If you enable user assignment required on the Cura enterprise app, remember to assign the pilot group. Otherwise assigned-only enforcement will block sign-in.

• If a policy blocks unapproved third-party applications, the Cura app needs adding to its exclusions or its allowed-app list.

One thing worth checking in advance. Cura identifies a user by the email address Microsoft returns, which is the user principal name. If your users' UPNs are on a different domain from the email address they actually use, tell your Cura contact both domains so we can map them to your workspace. This is the single most common cause of a user being told they have not been invited when they have.

When it is not configured

---

Google Workspace

These are sign-in scopes only. They allow Cura to confirm who the user is and read their name and email address. They grant no access to Gmail, Drive, Calendar or any other Workspace data, and Cura stores no Google token.

If your Workspace uses API access control to restrict third-party apps, mark the client above as trusted: in the Google Admin console, open Security > Access and data control > API controls > Manage third-party app access, choose Configure new app > OAuth App Name Or Client ID, enter the client ID, and set it to Trusted for the pilot group or the whole organisation.

---

Magic Link and email security scanners

A Magic Link is a single-use sign-in link sent by email. It expires 15 minutes after it is sent and can be used once.

Cura's sign-in links are designed to survive email security scanning, and this needs no exception from you. That is worth explaining, because it is the failure most often blamed on the client's mail filter when it is really the vendor's design.

Link protection products, including Microsoft Defender Safe Links and Zscaler, fetch every URL in a message shortly after it arrives, to check it. A conventional single-use sign-in link is spent by that fetch: the scanner consumes it, and the real recipient arrives to be told the link has expired. Cura hit this in testing, where a scanner spent a link 24 seconds after it was sent.

So a Cura sign-in link is deliberately two steps. Opening it does not sign anyone in. It opens a plain page with a single Sign in to Cura button, and only pressing that button completes sign-in. Scanners fetch pages but do not press buttons, so the link is still unused when your user opens it. There is no automatic redirect on that page, by design.

The practical consequences for you:

• Safe Links and equivalent products can stay switched on. Link rewriting is fine; the rewritten URL still resolves to the same confirmation page.

• You do not need a URL allowlist exception for sign-in to work, though you may still want one so links are not delayed by detonation.

• Invitation links are safe to scan too. They last 14 days, are not consumed when opened, and grant no access on their own; they simply open the sign-in page with the address filled in.

• If a user is told the link has already been used and they did not use it, something opened it first. They can request a new one and press the button on the page it opens.

---

Email delivery

Getting this right matters more than anything else on this page: an invitation or sign-in link that sits in quarantine looks to your people like a product that does not work.

Sender identity

Authentication

Mail from Cura is DKIM-signed with a key published on cura-tv.com, so it passes DMARC through DKIM alignment. If your gateway evaluates DMARC, Cura's mail authenticates. Your Cura contact can supply the current published records if your team wants to verify them independently before launch.

What to allow

The address to permit is [email protected], or the sending domain cura-tv.com.

In Microsoft 365, the supported route is a Tenant Allow/Block List entry for the sender domain, in the Defender portal under Policies & rules > Threat policies > Tenant Allow/Block Lists. If your anti-spam policy quarantines bulk mail aggressively, also confirm that transactional mail from this domain is not caught by the bulk complaint level.

In Google Workspace, add the domain to an allowed-senders list under Apps > Google Workspace > Gmail > Spam, phishing and malware, scoped to the pilot group if you prefer.

Please do not bypass filtering by IP address. Microsoft's own guidance discourages IP allowlisting or connection filtering for this purpose, and it is both broader and less reliable than a sender-domain allow entry: it can suppress spoof protection for anything sharing the provider's infrastructure. A domain-scoped allow entry is the right tool and is all Cura needs.

Test delivery before you invite anyone

Ask your Cura contact to send one invitation to a single pilot mailbox, then confirm it arrives in the inbox rather than junk or quarantine, that the sender shows as Cura, and that pressing the button in the email signs that user in. Do this a few days before launch, not on the day.

---

Who can sign in

Access is invitation-only. There is no public sign-up, and no one can reach your workspace by guessing its address.

• Email domains are matched exactly. If your people use more than one domain, or regional domains such as eu.example.com, each one must be registered against your workspace separately. A subdomain does not inherit from its parent, so [email protected] will not be recognised by an example.com entry.

• By default only invited people can sign in, even from a registered domain. Your workspace administrator can optionally allow anyone with a registered domain to join themselves, which is useful for a large pilot but means Cura will create accounts without an explicit invitation.

• Your workspace has a seat limit agreed for the pilot. Once it is reached, further sign-ups are declined rather than silently exceeding it.

• Leavers are handled by your administrator, who can suspend or remove a user. A suspended or removed user is refused at sign-in immediately.

---

Rolling out to your pilot group

• Stagger large invitation batches. Sign-in requests are rate limited per source network address. If several hundred people are invited at once and your organisation reaches the internet through a single shared address, a burst of simultaneous sign-ins can hit that limit and users will be asked to wait a moment. Inviting in batches over a few hours avoids it entirely.

• Test with one account first, end to end, using the checklist below.

• Tell your service desk what to expect, in particular that the sign-in email contains a link to a page with one more button on it. That is the design, not a fault.

---

Media, live events and analytics

Most environments need nothing here. It matters only where a proxy inspects or restricts streaming media.

• On-demand video is served from cdn.cura-tv.com as standard HLS over HTTPS, using short-lived signed URLs. Audio versions come from cura.b-cdn.net.

• Live events stream from *.playback.live-video.net, with event chat over a WebSocket to edge.ivschat.eu-west-1.amazonaws.com. Both are needed only while a live event is running.

• Product analytics load only after a user accepts the cookie banner. If accepted, the browser also contacts www.googletagmanager.com and t.contentsquare.net. If your policy is to block these, Cura continues to work normally without them.

---

Test and sign-off checklist

---

Troubleshooting

---

What Cura needs from you

• The tenant name you want in your workspace address.

• Every email domain your pilot users sign in with, including regional and legacy domains, and the UPN domain if it differs.

• Which sign-in routes you are enabling: Microsoft, Google, Magic Link, or a combination.

• A pilot mailbox to run the delivery test against.

• A named IT contact for launch week.

Your Cura contact can join a call with your IT team to walk through any of this.