Ask any business leader if they’re OK relaxing their mobile security standards and they’ll quickly tell you it’s not an option. But as mobile apps transition from standalone experiences to integral parts of an overall physical/digital ecosystem, securing them becomes more complex and more dynamic—a job well beyond the duties of mobile app developers.

Mobile developers are, by definition, people that write code for mobile devices. While their job often requires attention to other parts of a mobile-enabled business process, if the activity doesn’t influence an end-user experience, mobile developers won’t be passionate about it. As a result, enterprises become faced with an age-old challenge: How do you produce high-quality, secure applications when the developers are not motivated to meet those same goals?

(Related: NIST releases a guide to mobile app security)

The answer: Don’t place the sole responsibility for securing mobile apps on individual developers. Instead, drive security through a coordinated effort between the business and development teams. To do so, organizations should follow four key steps.

First, define mobile security at the corporate level to remain consistent across all apps. This requires companywide app classification. Within each class, you should define the individual aspects of the app to be secured and the strategy for implementing each aspect. These policies should be able to be updated as new security scenarios are encountered or corporate governance changes occur. Flexibility is key!

Then, rather than have app developers write code to secure data connections, encrypt local data, and create appropriate login screens, they should now simply denote in the code where these aspects occur. This way, if corporate policy changes, what was once unsecured may now be secured without requiring new development efforts. The markup can simply be metadata or comments that wrap the aspect in question.

Once the security policies are defined and source code is marked up, use build tools to apply these security policies through best-practice implementations. Doing so won’t be a static application. Because mobile security has many layers, the teams will want to make sure that the policies applied can be altered as different conditions arise in real time. For example, the CEO will have different mobile app permissions and security controls while he’s in the office than the newly hired associate who’s on vacation.

Finally, map deployed apps to existing security policies. As a given policy changes, apps can be flagged for updates that will bring them back into compliance. Because this process should rarely require direct development efforts, developers can spend their time doing what they love: creating engaging new experiences for consumers.

Currently there are no products on the market that deliver on the complete abstraction of mobile application security development outlined above. However, vendors are beginning to see the opportunity for innovation. As a result, they are filling the space with two kinds of solutions that take security considerations out of the hands of individual developers and place them closer to the line-of-business and operational units.

Binary application wrapping enforces security without code changes, which allows any application to be secured regardless of the availability of source code and developers. But this approach limits the types of security controls that can be implemented. The second approach from SDK-based application security vendors provides the deepest security with the best user experience, but it’s costly to implement and requires that the SDK be compiled into the program prior to use.

While we don’t consider these new vendor technologies to be enterprise-ready, these advancements show promise for the future of mobile app security development—a domain that is ripe for innovation and technology advancement. In order for a vendor to succeed at providing a top-of-the-line solution, they must have great insight into business needs around security and developer workflows, and be able to coordinate the tools across all business units.