Security should fit the situation.
At development.city, we follow a principle we call Right-Sized Security: different services and types of information require different levels of access, authentication, and protection.
The goal isn't to make every experience difficult to use.
The goal is to provide the right balance between convenience, privacy, security, and control.
1. Right-Sized Security
Not every digital interaction carries the same level of risk.
Booking a meeting is different from accessing a private project environment.
Reading public information is different from accessing confidential documents.
That's why we don't believe in using exactly the same access model everywhere.
Instead, we consider:
What information is involved?
Who needs access?
What actions can they perform?
How sensitive is the information?
What level of authentication is appropriate?
How can we keep the experience practical for the people using it?
Security should protect the experience, not unnecessarily obstruct it.
2. Different Access Levels
Depending on the service and the information involved, development.city may use different approaches to authentication and access.
These can include:
Public Access
Some information and services are intentionally available without authentication.
This keeps public resources easy to discover and use.
Standard Account Access
Some services may require an account and authenticated access while still prioritising convenience and ease of use.
Passwordless Access
For environments where stronger control is appropriate, passwordless authentication can be used to reduce the risks and friction associated with traditional passwords.
Restricted Access
Sensitive environments may be limited to specifically authorised customers, partners, team members, or other approved users.
The exact authentication method can vary depending on the service.
The principle remains the same: access should match the sensitivity of what is being protected.
3. Separation of Environments
One of the important principles of good digital architecture is compartmentalisation.
Not everything needs to live in the same environment.
Separating different services, workflows, and data environments can help limit unnecessary access and reduce the potential impact of a problem affecting one part of the ecosystem.
This can also make permissions easier to understand and manage.
Think of it like a physical city.
You don't give everyone a key to every building simply because they live in the same city.
Different places have different access requirements.
4. Privacy by Design
Security and privacy are closely connected, but they aren't the same thing.
Security focuses on protecting information and systems.
Privacy also asks:
Should we have this information in the first place?
We therefore aim to minimise unnecessary collection, sharing, and retention of personal information.
Where data is required for a service, we aim to make its purpose understandable and handle it responsibly in accordance with applicable data-protection requirements.
The best data to protect is often the data you never needed to collect.
5. Authentication & Identity
Authentication is about establishing that someone is authorised to access a particular service or environment.
Different services may therefore use different authentication mechanisms depending on their requirements.
These can include:
Account-based authentication
Federated or social identity providers
Passwordless authentication
Email-based verification
Other appropriate authentication methods
We evaluate the method according to the purpose and sensitivity of the environment.
Convenience matters.
Security matters.
The right solution balances both.
6. Access Control
Authentication answers:
Who are you?
Access control answers:
What are you allowed to access?
These are different questions.
A user may be authenticated but still not have permission to access every project, document, service, or administrative function.
Where appropriate, access can therefore be limited according to:
User identity
Organisation
Project
Role
Service
Permission level
Other relevant conditions
This principle of least necessary access helps reduce unnecessary exposure.
7. Protecting the Ecosystem
Security is not a single feature that can simply be switched on.
It is an ongoing process involving technology, configuration, access management, monitoring, updates, providers, policies, and — importantly — people.
We therefore consider security throughout the lifecycle of our infrastructure.
That includes evaluating:
The services and technologies we use
How information moves between systems
Who can access different environments
How credentials and authentication are handled
How integrations are configured
How changes are introduced
What happens when something goes wrong
No system can honestly be described as completely risk-free.
Our responsibility is to reduce unnecessary risk, respond appropriately, and keep improving.
8. Security Without the Theater
Security shouldn't be about impressive terminology.
It should be about practical protection.
We don't believe that adding more passwords, more authentication steps, or more complexity automatically creates better security.
Likewise, making everything frictionless isn't automatically secure.
Good security requires judgement.
Sometimes the right answer is:
Make access easier.
Sometimes it is:
Add another layer of verification.
Sometimes it is:
Don't collect the information at all.
The right decision depends on the situation.
9. Your Responsibility Matters Too
Security is a shared responsibility.
We can design and operate infrastructure with appropriate safeguards, but users also play an important role.
We ask users to:
Keep their email accounts and devices secure
Protect authentication links and credentials
Avoid sharing access with unauthorised people
Use trusted devices and networks where appropriate
Report suspicious activity or unexpected access
Keep their contact and account information accurate
If something doesn't look right, tell us.
Early reporting can make a significant difference.
10. An Evolving Approach
Technology changes.
Threats change.
Authentication methods change.
The infrastructure behind development.city will continue to evolve as well.
That means our security practices cannot simply remain frozen in time.
We review and improve the way access, privacy, authentication, and infrastructure are handled as the ecosystem develops.
Security is not a destination. It's part of the infrastructure.
The Short Version
Public information should be easy to access.
Private information should be appropriately protected.
Sensitive environments should have stronger controls.
Users should have only the access they need.
And wherever possible:
Collect less. Protect what matters. Keep people informed.
That's Right-Sized Security.
Build better. Connect smarter. Scale sustainably.
#ForPeopleForPlanet