A staff directory that exposes personal details to the wrong audience is not a minor intranet issue. Nor is a news app that requires a separate login, sends employee data to an external platform or gives itself more access than it needs. What makes SharePoint apps secure is not one feature or a reassuring badge. It is the combination of where the app runs, how it authenticates users, what permissions it requests and how it handles your organisation’s data.

For organisations already using Microsoft 365, the practical question is simple: does this app work within the controls you already trust, or does it create a new place where information, identities and risk must be managed?

What makes SharePoint apps secure by design?

A well-built SharePoint app should work with Microsoft 365 rather than around it. That means using the signed-in employee’s existing identity, respecting the permissions already set on SharePoint content, and keeping information within the tenant unless there is a clearly stated and necessary reason not to.

Modern SharePoint web parts are commonly built using the SharePoint Framework, known as SPFx. This is Microsoft’s development framework for extending modern SharePoint pages. It matters because SPFx web parts run in the Microsoft 365 environment and can use the platform’s established identity, permission and compliance controls.

That does not make every SPFx app automatically safe. The framework provides sensible foundations, but the developer still decides what data to request, which services to call and whether an external system is involved. Security depends on those decisions being restrained, transparent and appropriate to the job the app performs.

For example, a news carousel should need access to the news content it displays, not broad access to every document library in the tenant. An employee directory may need approved profile fields, but it should not expose restricted HR information simply because it is technically available. Good app design starts with the minimum access required, then avoids collecting or processing anything else.

Security begins with Microsoft 365 identity

Separate usernames and passwords are an avoidable problem in many business applications. They increase support calls, encourage password reuse and make it harder to remove access promptly when someone leaves.

A SharePoint app that uses Microsoft 365 sign-in avoids this extra identity layer. Employees access it using the account they already use for SharePoint, Teams and other Microsoft 365 services. Controls such as multi-factor authentication, conditional access policies and account lifecycle management remain relevant without the app needing to reproduce them.

The key benefit is consistency. If a user cannot access a restricted SharePoint site, library or list, the app should not provide a route around that decision. If their account is disabled, their access to the web part ends with it. This is much easier to govern than a separate application with its own user database and offboarding process.

There is a trade-off. Some more complex solutions use a separate external application because they need capabilities that SharePoint alone does not provide. That can be legitimate, but it changes the security conversation. You then need to understand where user data is stored, how authentication is handled, what contractual safeguards apply and who monitors the additional service. For a straightforward intranet feature, that added complexity is often unnecessary.

Permissions should follow the user

SharePoint’s permission model is useful precisely because it is already part of how most organisations control documents, pages and sites. A secure app should honour those existing permissions rather than copy data into a new repository or show the same result to everyone by default.

Consider an intranet search feature. A secure implementation returns content only where the person searching already has permission to view it. The same principle applies to personalised document views, calendar displays and news. Personalisation should improve relevance, not weaken access control.

This is why permission scope deserves scrutiny during procurement and installation. Tenant administrators should ask what permissions an app requests and why. Broad permissions are not always wrong, particularly where an app has a genuine tenant-wide function, but they should be easy to explain in plain English.

Look for clear answers to questions such as these: Does the app read only the SharePoint content it displays? Can it write or delete content? Does it access user profile information? Does it act on behalf of the signed-in user, or with wider application permissions? Is access limited to selected sites or available across the tenant?

An app supplier should be able to answer without hiding behind technical language. If the explanation is vague, the permissions are probably not ready for approval.

Least privilege is practical, not theoretical

The principle of least privilege means giving an app only the access it needs to do its work. It is one of the simplest ways to reduce the impact of a configuration error, a compromised account or a future change in the app’s behaviour.

It also makes governance easier. An intranet owner can understand why a people directory reads profile fields. It is harder to justify why the same directory requires access to mailboxes, files or unrelated business data. Narrower permissions create a clearer audit trail and fewer difficult questions later.

Keep intranet data in the tenant where possible

For many organisations, the strongest practical security boundary is their Microsoft 365 tenant. It is where their user identities, SharePoint content, retention settings, audit records and access policies already sit. Keeping a web part and its data processing within that boundary reduces the number of systems that need review.

This is especially relevant for employee-facing apps. Recognition posts, poll responses, staff profiles and personalised views can all contain information that may be sensitive in context, even if it is not formally classified. Sending that information to an external hosting platform creates another data processor, another location to assess and another set of operational dependencies.

ThePoint’s SharePoint Experience Pack is designed on this basis. Its SPFx web parts work natively within Microsoft 365, with no external hosting and no data leaving the tenant. That does not remove the need for sensible configuration, but it avoids introducing a separate platform simply to add an intranet feature.

Keeping data in the tenant is not an absolute rule. Some integrations genuinely require external services, and a business may accept that arrangement after proper due diligence. The point is to make the decision deliberately. Ask where data travels, whether it is stored, how long it is retained and whether it can be used for any purpose beyond delivering the service.

Secure development and change control still matter

An app can have the right architecture and permissions, then become a problem through poor maintenance. Secure SharePoint apps need a disciplined development process: code review, controlled releases, testing against realistic permission scenarios and a route for addressing vulnerabilities when they are found.

For buyers, this does not mean asking to inspect every line of source code. It means checking whether the supplier has a credible operating model. Can they explain how updates are released? Do they test compatibility with current Microsoft 365 changes? Is there a clear support route if an issue affects users? Are configuration changes documented so an administrator can understand what was enabled?

Microsoft 365 changes regularly, and intranets change with the organisation. New sites appear, staff structures move, permission models evolve and retention policies tighten. A web part that is secure at installation can still create risk if no one reviews it after material changes to the tenant.

That is where ownership matters. The intranet owner, IT team and supplier each have a role. The supplier should maintain the product and communicate relevant changes. The organisation should manage its Microsoft 365 identities, permissions and governance settings. Neither side can sensibly assume the other is handling everything.

Installation should be controlled, not cumbersome

Fast deployment and security are not opposites. A production-ready web part can install in minutes while still being subject to the right approval process. The difference is that the process should focus on meaningful checks rather than turn into a lengthy custom development review.

Before approving an app, confirm the publisher, review requested permissions, establish whether external hosting or data transfer is involved, and decide who can configure the app after installation. Test it first in a suitable non-production environment where that is available, particularly if it will display sensitive content or be used across the whole organisation.

Then test real-world scenarios. Check what a standard employee sees, what a site owner can change and what happens when content is restricted. Test with users from different departments if the app uses audience targeting or personalised views. These checks are usually quick, and they reveal more than a generic security questionnaire.

The secure choice is usually the simpler one

The best SharePoint app is not the one with the longest security statement. It is the one that has a clear and limited purpose, uses Microsoft 365 identity, respects existing permissions and does not move data elsewhere without a good reason.

That approach gives IT teams fewer accounts to manage, fewer systems to assess and less duplicated information to protect. It also gives intranet owners the freedom to improve the employee experience without creating a parallel technology estate. Before adding the next web part, ask one practical question: does it fit the controls your organisation already uses, or does it ask you to build new ones around it?